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ABSTRACT 


The  necessity  for  well-defined,  integrated  information  systems  (IS),  .driven 
by  today’s  dwindling  human,  financial,  and  management  resources,  makes  it 
essential  to  plan  effectively.  This  can  only  be  achieved  by  linking  IS  planning  to 
the  overall  strategic  plan  of  the  organization.  Department  of  the  Navy  (DON) 
IS  planning  has  historically  missed  the  mark  in  this  respect.  Information 
Engineering  (IE),  automated  through  Computer  Aided  Software  Engineering 
(CASE)  technology,  offers  significant  benefits  for  improving  DON  IS  planning. 
Two  CASE  workbenches.  Information  Engineering  Systems  Corporation’s  USER: 
Expert  Systems  and  Texas  Instruments’  Information  Engineering  Facility,  have 
proven  highly  effective  in  automating  IE  in  DON  applications. 
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I.  INTRODUCTION 


The  management  of  information  systems  (IS)  development  in  the 
Department  of  the  Navy  (DON)  has  historically  suffered  from  the  lack  of  a  solid 
planning  foundation,  as  evidenced  by  the  proliferation  of  non-integrated, 
redundant,  application-driven  systems  that  exist  throughout  the  service.  This  is 
due  to  a  variety  of  reasons.  First,  planners  suffer  from  the  fact  that  they  deal 
with  an  uncertain  and  distant  future,  •  ath  the  possibility  of  achieving  no  tangible 
benefits  until  long  after  the  incumbent  planner  has  departed.  As  such,  planning 
is  perceived  by  many  as  a  significant  and  unnecessary  resource  drain.  In  addition, 
forecasting  inaccuracies  due  to  inadequate  knowledge  of  the  social,  political, 
cultural,  and  economic  forces  at  work  in  the  environment  add  elements  of  risk 
and  uncertainty  that  further  complicate  the  planning  effort.  Differences  in 
perceptions  regarding  organizational  priorities  and  industry  trends  between  top 
management  and  IS  personnel  also  adversely  affect  planning.  Finally,  planning 
has  often  been  carried  out  as  a  meaningless,  mandated,  ritual  rather  than  as  a 
highly  utilized  operational  tool.  All  these  factors  lead  to  a  lack  of  commitment 
from  top  management  down,  thereby  undermining  the  overall  IS  planning  effort 
of  the  organization. 
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A  heavy'  price  may  be  paid  as  a  result  of  inadequate  IS  planning.  Without 
the  benefit  of  a  solid  planning  foundation,  information  and  integration 
requirements  are  often  short-sighted  and  incomplete,  and  as  such,  represent  the 
basis  for  systems  that  will  not  meet  the  overall  information  needs  and  mission  of 
the  organization.  The  result:  huge  software  maintenance  costs  comprising  up  to 
eighty  percent  of  total  lifecycle  costs.  On  the  other  hand,  an  effective  planning 
effort  will  serve  as  a  basis  for  systems  that  promote  corporate  strategy,  improve 
overall  performance,  and  facilitate  communications  between  management  and 
systems  personnel. 

Despite  the  unfavorable  perceptions  that  exist  regarding  planning,  there  are 
considerable  pressures  to  plan  effectively.  First,  in  today’s  budget  climate, 
effective  planning  is  vital  to  ensure  continued  funding  for  systems  throughout  their 
lifecycle.  For  FY  1990,  the  House  of  Representatives  Committee  on 
Appropriations  mandated  cuts  of  $300.75  million  in  the  Department  of  the  Navy 
ADP  budget,  including  a  $70  million  cut  directly  attributable  to  Navy 
mismanagement  of  ADP  programs.  [Ref.  1:p.  39]  As  a  result,  there  will  be 
increased  emphasis  on  strategic  and  IS  planning  in  the  future  to  prevent  huge  cost 
growths,  redundant  systems,  and  development  of  systems  that  do  not  meet 
strategic  information  needs  of  the  organization.  Secondly,  rapid  changes  in 
technology  emphasize  the  importance  of  planning  at  all  levels  in  order  to  avoid 
the  proliferation  of  incompatible,  incomplete  information  systems.  Finally,  the 
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necessity  for  efficiency,  driven  by  dwindling  human,  financial,  and  management 
resources  available  to  organizations,  make  it  essential  to  plan  effectively.  As  the 
vision  of  information  as  a  corporate  resource  continues  to  evolve,  there  will  be 
increasing  motivation  to  develop  integrated,  organization-wide  information  systems. 
These  systems  can  be  successful  only  if  the  development  process  is  based  on  a 
solid  foundation  of  strategic  information  systems  planning. 

As  the  significance  of  information  systems  to  fulfilling  the  corporate  mission 

increases,  so  does  the  necessity  to  link  systems  planning  with  the  strategic 

objectives  of  the  organization.  Aligning  the  strategic  information  systems  plan  to 

the  corporate  strategic  plan  will  ensure  that  the  organization  will  be  in  a  position 

to  exploit  emerging  technologies  and  industry  trends,  while  continuing  to  develop 

systems  that  fully  support  its  information  requirements.  Establishing  the  linkage 

between  strategic  and  IS  planning  is  essential  for  an  organization  in  many  ways: 

First,  it  is  important  to  know  how  a  change  in  the  strategic  planning  of  an 
organization  would  affect  the  planning  of  information  technology  because 
changes  in  the  infrastructure  of  an  organization  take  years  to  evolve.  It  is 
important  to  analyze  these  changes  early  and  identify  the  cultural  issues  that 
are  unique  to  each  organization  because  a  significant  level  of  planning  and 
resources  is  needed  for  cultural  change  to  happen.  Second,  senior  executives 
strongly  desire  to  regain  effective  control  in  the  aftermath  of  the  information 
technology  explosion.  This  control  can  be  achieved  through  strategic 
planning  at  both  organizational  and  technological  levels  in  order  to  align 
development  efforts  with  strategic  business  objectives,  plans,  and  priorities. 
This  desire  is  due  largely  to  senior  executives’  recognition  that  information 
systems  are  becoming  the  critical  path  in  effecting  critical  changes  in  an 
organization.  [Ref.  2:p.  218] 
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Many  methodologies  and  tools  have  been  introduced  throughout  the  years 
designed  to  improve  the  process  of  developing  computer-based  information 
systems.  The  vast  majority  of  these  methods  have  fallen  woefully  short  in  support 
of  strategic  systems  planning.  However,  two  methodologies  have  proven  effective 
for  aligning  strategic  and  information  systems  planning.  [Ref.  3:p.  448]  The  first. 
Business  Systems  Planning  (BSP)  was  developed  in  the  late  1960’s  by  IBM,  and 
was  the  first  systems  development  methodology  to  recognize  the  need  to  link  IS 
planning  to  strategic  planning,  and  to  emphasize  data  as  a  corporate  resource. 
[Ref.  4:p.  103]  The  second,  Information  Engineering,  was  developed  in  the  1970’s 
by  James  Martin  and  Clive  Finkelstein  as  a  strategic  information  systems 
development  methodology  supporting  the  entire  lifecycle.  [Ref.  3:p.  449]  This 
thesis  will  examine  and  compare  them,  and  discuss  the  suitability  of  using  each 
in  the  context  of  Department  of  the  Navy  (DON)  applications. 

The  thesis  examines  the  efforts  of  the  Department  of  the  Navy  in  aligning 
strategic  and  information  systems  planning,  and  will  present  recommendations  for 
facilitating  this  process.  SECNAV  Instruction  5230.9A,  the  Information  Resource 
(TR)  Program  Planning  guide,  and  SECNAV  Instruction  5230.10,  the  Department 
of  the  Navy  Strategic  Plan  for  Managing  Information  and  Related  Resources 
(IRSTRATPLAN),  document  the  Navy’s  commitment  to  a  top-down  approach  to 
strategic  IS  planning.  However,  in  practice,  its  efforts  have  not  been  particularly 
successful.  Huge  cost  overruns,  unnecessary  duplication,  the  inability  to  integrate 
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existing  systems,  and  overall  program  mismanagement  have  resulted  in  a  loss  of 
credibility  and  confidence  for  the  DON  in  Congress.  There  are  several  reasons 
for  these  difficulties.  One  of  the  primary  reasons  is  the  lack  of  understanding  by 
top  DON  management  of  Information  Resource  Management  (IRM)  issues,  and 
in  particular,  the  methodologies  and  tools  available  for  aligning  its  overall 
strategic  planning  and  IS  planning.  Uneasiness  regarding  the  need  for  IRM  and 
IR  planning,  the  organizational  structure  required  to  support  IRM,  and  the 
relative  strengths  and  weaknesses  of  the  various  IS  planning  tools  and 
methodologies,  all  add  to  the  reluctance  of  top  management  to  embrace  these 
issues.  Second,  the  reluctance  of  top  management  to  commit  considerable 
resources  to  what  is  perceived  to  be  an  uncertain  process,  further  complicate  the 
IRM  and  IR  planning  process.  It  is  important  for  DON  management  to 
understand  that  IS  planning  methodologies  are  not  a  panacea  and  do  not  provide 
an  overnight  payback.  The  large  up  front  investment  in  time  and  capital  required 
will  yield  benefits  downstream,  and  over  the  long  run,  not  overnight.  A 
commitment  to  education  at  all  levels  of  both  the  IS  and  line  communities  is 
required  to  improve  the  overall  performance  of  DON  system  development  and 
program  management.  In  addition,  environmental  factors  such  as  political  issues, 
budgetary  constraints,  and  the  inefficiencies  of  the  Life  Cycle  Management  (LCM) 
process  when  applied  to  IS  development  and  acquisition,  further  hinder  IRM  and 
IR  planning  efforts  in  the  DON. 
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The  thesis  will  address  the  following  questions: 


1.  Which  CASE  tools  are  the  most  suitable  for  aligning  strategic  and  IS 
planning  in  the  Department  of  the  Navy  (DON)? 

2.  Why  have  IS  planning  methodologies  been  under-utilized  in  the  DON? 

3.  Are  DON  organizations  the  size  of  Type  Commanders  (TYCOMS),  such 
as  CINCLANT,  or  Systems  Commands  (SYSCOMS),  such  as  NAVSEA  or 
NAVSUP,  too  large  and  complex  to  effectively  utilize  these  methodologies 
in  support  of  IS  planning  efforts? 

4.  Are  DON  activities  effectively  aligning  their  IS  plans  to  the  overall 
strategic  objectives  of  their  organization  and  the  DON  as  a  whole? 

5.  What  are  the  benefits  to  the  organization  of  applying  IS  planning 
methodologies  to  systems  development  projects? 

6.  Is  Information  Engineering  suitable  for  use  as  a  strategic  planning  tool 
outside  the  realm  of  ADP? 


Chapter  II  will  provide  background  information  on  the  interrelationship  and 
importance  of  strategic  planning  and  information  systems  planning.  In  addition, 
it  will  examine  the  strengths  and  weaknesses  of  Information  Engineering  and 
Business  Systems  Planning  as  IS  planning  methodologies. 

Chapter  III  will  evaluate  IR  planning  in  the  Department  of  the  Navy,  by 
examining  the  planning  process,  and  the  difficulties  currently  hindering  the 
process.  In  addition,  it  will  examine  the  potential  implications  of  the  DoD- 
directed  Corporate  Information  Management  (CIM)  initiative. 

Chapter  IV  will  discuss  the  benefits  of  applying  Information  Engineering  and 
Computer  Aided  Software  Engineering  (CASE)  technology  to  the  DON  IR 
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planning  process,  and  will  present  recommendations  to  facilitate  its  use.  It  will 
then  examine  and  compare  three  commonly  used  CASE  workbenches  that 
automate  some  or  all  of  the  Information  Engineering  process.  In  addition,  the 
lifecycle  coverage  of  these  toolsets  will  be  compared  in  the  context  of  an 
analytical  framework  for  comparing  information  engineering  methodologies, 
developed  by  Hackathom  and  Karimi.  [Ref.  2:p.  204]  The  following  CASE 
workbenches  will  be  examined: 

1.  Information  Engineering  Systems  Corporation’s  "User:  Expert  Systems", 

2.  Texas  Instrument’s  "Information  Engineering  Facility", 

3.  KnowledgeWare’s  "Information  Engineering  Workbench" 

Finally,  Chapter  V  will  present  conclusions  and  recommendations  for 
improving  the  IR  planning  efforts  of  the  Department  of  the  Navy. 
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II.  ALIGNING  STRATEGIC  AND  INFORMATION  SYSTEMS  PLANNING 


A.  STRATEGIC  PLANNING 

Strategic  planning  is  the  process  of  deciding  on  objectives  of  the 
organization,  on  changes  in  these  objectives,  on  the  resources  used  to  attain 
these  objectives,  and  on  the  policies  that  are  to  govern  the  acquisition,  use, 
and  disposition  of  these  resources.  Strategic  planning.  .  .  is  a  process 
having  to  do  with  the  formulation  of  long  range,  strategic  plans  and  policies 
that  determine  or  change  the  character  or  direction  of  the  organization. 
Robert  Anthony  [Ref.  4:p.  8] 

From  the  definition,  one  can  see  that  strategic  planning  is  proactive  in 
nature,  and  deals  with  issues,  impacts,  and  potential  strategies  for  accomplishing 
business  objectives.  It  is  a  comprehensive,  iterative,  three-stage  process  for 
exercising  favorable  influence  over  future  events.  The  process  starts  with  strategic 
planning  and  continues  through  strategic  implementation  and  strategic 
management.  As  a  result  of  feedback  during  the  implementation  and 
management  of  the  plan,  it  is  continuously  refined.  (Figure  1)  In  the  first  stage, 
the  organization  is  analyzed  to  determine  where  it  stands,  and  where  it  must  go. 
This  analysis  examines  the  organization  as  a  dynamic  and  adaptable  system  that 
is  affected  by  and  interrelates  with  the  following  forces:  external,  social,  cultural, 
political,  economic,  and  competitive.  [Ref.  6:p.  205]  Understanding  these  forces, 
how  they  interrelate,  and  what  threats  and  opportunities  they  create,  is  vital  for 
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Figure  1.  Strategic  Planning  Life  Cycle  [Ref.  5:p.  160] 
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effective  strategic  planning.  In  addition,  the  availability  and  development  of 
corporate  resources  such  as  plant  and  equipment,  personnel,  capital,  and  data 
must  be  considered.  From  this  organizational  analysis,  goals  and  objectives  are 
set,  and  strategies  for  achieving  these  goals  must  be  developed.  For  example,  a 
typical  strategy  statement  would  be:  "Effectively  manage  inventory".  In  stage  two, 
these  strategic  directions  are  communicated  to  the  organization  via  the  setting  of 
management  objectives,  and  then  implemented  through  supporting  strategic, 
tactical,  and  operational  plans  and  policies.  At  this  point,  the  strategy  statement 
has  been  refined  and  strengthened  to  include  specific  plans  and  policies  for 
executing  the  strategy.  Thus,  the  above  strategic  statement  is  supplemented  with 
statements  such  as:  "Adjust  inventory  levels  according  to  demand  or  in  accordance 
with  policy",  or  "Prioritize  inventory  management  by  mission  essentiality."  Finally, 
in  stage  three,  these  plans  and  policies  are  executed  and  managed  by  the 
organization.  During  this  stage,  feedback  and  performance  criteria  must  be 
monitored  to  ensure  the  success  of  the  organization.  Problems  in  the  plan  are 
identified,  and  refinements  are  instituted  as  necessary. 

B.  STRATEGIC  INFORMATION  SYSTEMS  PLANNING 

In  organizations  where  information  is  a  vital  resource,  such  as  the 
Department  of  the  Navy,  strategic  planning  and  information  systems  planning  must 
be  closely  tied.  The  IS  planning  process  must  be  an  integral  part  of  the  overall 
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business  plan  of  the  organization  in  order  to  achieve  the  optimal  fit  between 
organizational  requirements  and  IS  functions.  [Ref.  7:p.  4]  An  effective 
information  systems  plan  that  has  been  closely  aligned  to  strategic  business 
objectives  holds  significant  advantages  for  the  organization.  First,  it  promotes 
commitment  from  top  level  management,  as  they  will  be  more  willing  to  provide 
adequate  resources  for  systems  that  are  strategically  important,  and  from 
information  systems  personnel  by  making  them  stakeholders  in  the  success  of  the 
organization.  Second,  it  enhances  both  lateral  and  vertical  communications  within 
the  organization  since  all  components  are  supporting  mutually  agreed  upon 
objectives.  Third,  an  effective  strategic  IS  plan  provides  focus  and  constraints  on 
resource  allocation  by  narrowing  the  scope  of  organizational  objectives.  Similarly, 
the  project  selection  process  is  streamlined  by  the  assurance  that  only  those 
projects  which  directly  support  the  business  and  IS  plans  will  be  developed.  The 
requirement  to  develop  systems  that  "put  out  fires"  will  be  reduced.  Finally,  the 
strategic  IS  plan  provides  a  vehicle  for  managing  changes  in  technological, 
environmental,  and  organizational  climate.  By  anticipating  and  planning  for  future 
requirements,  the  strategic  IS  plan  facilitates  the  timely  and  orderly  introduction 
of  systems  designed  to  ensure  continued  organizational  success. 

In  general,  development  of  an  effective  IS  strategic  plan  supplements  the 
formulation  of  the  strategic  business  plan.  It  involves  a  three  step  process  starting 
with  strategic  IS  planning,  then  moving  to  tactical  IS  planning,  and  finally,  to 
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operational  IS  planning.  Strategic  IS  planning  links  organizational  needs  and 
information  resources  and  entails  evaluating  environmental  and  organizational 
factors,  deciding  on  objectives,  and  formulating  policies. 

Strategic  IS  planning  begins  with  a  determination  by  management  of  where 
the  organization  stands  in  the  evolution  of  its  data  processing  function.  Two  IS 
planning  models  are  highly  effective  at  determining  the  current  state  of 
employment  of  information  technology  and  information  systems  within  an 
organization:  McFarlan  and  McKenney’s  Strategic  Grid,  and  Nolan’s  Stages  of 
Growth  model. 

1.  The  Strategic  Grid 

For  some  organizations,  IS  activities  play  a  vital  and  strategic  role,  not 
only  in  their  daily  operations,  but  also  in  the  development  of  their  future 
applications  portfolio,  as  a  way  of  achieving  competitive  success.  On  the  other 
hand,  IS  activities  may  play  only  a  minor,  supporting  role  in  the  organization. 
Further  the  role  of  IS  in  the  organization  may  be  either  increasing  or  decreasing 
at  any  given  point  in  time.  Whatever  the  case,  it  is  vitally  important  for 
management,  both  IS  and  senior  -level,  to  examine  the  role  that  IS  plays  in  their 
organization.  The  Strategic  Grid  approach,  developed  by  McFarlan  and 
McKenney  of  Harvard  Business  School,  maps  the  role  and  strategic  impact  of 
IS  to  the  organization  in  -an  extremely  simple,  yet  highly  useful  manner. 
[Ref.  8:p.  152]  The  four  quadrant  grid  graphs  the  strategic  impact  of  existing 
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information  systems,  on  the  vertical  axis,  against  the  strategic  impact  of  the 
organization’s  planned  application  development  portfolio.,  on  the  horizontal  axis. 
(Figure  2)  Based  on  its  placement  on  each  of  the  two  axes,  an  organization  is 
mapped  into  one  of  the  four  quadrants:  Strategic,  Turnaround,  Factory,  and 
Support. 

Organizations  that  fall  into  the  Strategic  quadrant  are  critically 
dependent  on  the  efficient  daily  functioning  of  their  existing  IS  activity,  and  have 
applications  under  development  that  are  essential  to  their  continued  competitive 
success.  Banking  firms  and  airlines  are  excellent  examples  of  firms  that  reside 
in  the  Strategic  quadrant.  These  organizations  must  place  a  high  degree  of 
emphasis  on  IS  planning  in  order  to  maintain  a  proactive  stance.  To  do  this, 
there  should  be  little  organizational  distance  between  top  management  and  IS 
management.  In  addition,  clear  and  formal  lines  of  communication  should  be 
established  and  maintained  to  ensure  close  cooperation  between  the  two. 

There  are  many  organizations  that  are  highly  dependent  on  their  current 
IS  activities,  but  are  not  dependent  on  their  future  applications  portfolio  for 
continued  strategic  success.  These  organizations  fall  into  the  Factory  quadrant  of 
the  Strategic  Grid.  Large  manufacturing  and  distribution  firms  may  fall  into  this 
category.  Much  of  the  day-to-day  operations  of  these  organizations  is  dependent 
on  the  smooth  and  efficient  operation  of  their  IS  activity.  The  applications 
portfolio  of  these  firms  contains  maintenance  work  and  "back-room"  applications 
that,  although  important,  will  not  significantly  affect  the  ability  of  the  organization 


13 


to  compete.  As  a  result,  IS  planning  has  a  short  term,  operational  management 
perspective,  with  an  emphasis  on  cost  savings  and  efficiency. 

Other  organizations  depend  neither  on  their  current  IS  activities  nor 
their  future  applications  development  portfolio,  for  their  continued  strategic 
success.  These  organizations  fall  into  the  Support  quadrant.  Large  manufacturing 
firms  may  also  fall  into  this  quadrant.  In  these  organizations,  IS  management  is 
at  a  much  lower  organizational  level,  and  the  priority  placed  on  IS  planning  is 
equally  low. 

Many  firms,  on  the  other  band,  may  have  a  future  applications 
development  portfolio  that  is  vital  to  their  continued  ability  to  compete,  even 
though  the  strategic  impact  of  existing  IS  activities  is  low.  Rapidly  growing 
organizations  are  often  in  the  Turnaround  position.  These  firms  are  in  a 
transitionary  period  in  their  IS  development.  They  have  yet  to  develop  a  high 
dependency  on  IS  support,  yet  they  realize  the  strategic  importance  and  future 
competitive  benefits  of  information  systems.  As  a  result,  the  organizational 
position  of  IS  management  is  rising  to  reflect  its  new  strategic  significance. 
Further,  top  management  is  increasing  its  commitment  to  IS  planning  through 
"a  revised  reporting  structure,  increased  top-level  participation  in  IS  steering 
committees,  and  more  intense  user  involvement  in  establishing  priorities." 
[Ref.  9:p.  152]  An  organization  must  move  through  the  Turnaround  quadrant  in 
order  to  move  from  Support  to  Strategic.  This  is  implicitly  obvious  as  a  firm  in 
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the  Support  stage  must  make  a  commitment  to  increasing  the  strategic  significance 
of  its  applications  portfolio  in  order  to  move  on  to  the  Strategic  quadrant. 

The  Strategic  Grid  is  useful  not  only  for  characterizing  the  organization 
as  a  whole,  but  also  for  examining  the  role  of  IS  in  individual  business  units. 
This  is  important  as  individual  business  units  in  the  same  organization  may  have 
radically  different  positions  on  the  grid.  The  placement  of  an  organization  or  a 
business  unit  on  the  grid  has  several  important  implications.  First,  it  provides 
management  with  an  effective  diagnostic  tool  for  determining  where  they  stand 
in  terms  of  their  IS  activity,  and  therefore  gives  them  an  indication  as  to  where 
and  how  best  to  conduct  their  IS  planning  efforts.  It  also  provides  a 
comprehensive  picture  of  the  degree  to  which  IS  planning  efforts  must  be 
integrated  into  overall  organizational  planning.  The  actual  position  of  the 
organization  on  the  grid,  and  its  position  on  the  grid  as  perceived  by  senior  line 
and  IS  management  are  vital  inputs  to  the  IS  planning  process.  So  to,  is  the 
desired  position  on  the  grid  that  the  organization  wishes  to  attain.  Second,  it 
establishes  the  strategic  role  of  the  IS  function-  its  operations,  the  role  of  its 
management,  and  its  future  role  in  the  organization.  As  such,  it  provides 
management  with  a  toe1  determining  the  organizational  placement  of  IS,  and 
suggests  the  required  level  of  involvement  of  general  management  and  the  role 
of  the  executive  steering  committee.  Similarly,  it  suggests  an  appropriate  type  of 
management  control  system  for  the  organization  and  its  individual  business  units. 
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It  also  suggests  the  need  for  a  flexible,  dynamic  planning  and  control  approach 
when  the  role  of  IS  is  changing  over  time.  Finally,  it  serves  to  determine  the 
degree  of  importance  of  the  information  resource  to  the  organization,  and  the 
nature  of  effort  that  must  be  undertaken  to  develop  it.  As  such,  it  is  an  effective 
starting  point  for  any  strategic  IS  planning  effort.  The  main  disadvantage  of 
the  approach  is  that  it  doesn’t  provide  any  tools  or  clear  criteria  for  determin¬ 
ing  where  an  organization  or  business  unit  should  be  located  on  the  grid. 
[Ref.  7:p.  12]  This  is  left  up  to  the  subjective  evaluation  of  management. 
Determining  the  location  of  the  DON  on  the  grid  is  a  significant  task  because  of 
its  complexity,  and  the  varying  degrees  of  importance  that  information  technology 
plays  in  its  organizations. 

2.  Nolan’s  Stages  Of  Growth 

Nolan’s  Stages  of  Growth  is  a  six-stage  model  that  examines  the  growth 
of  an  organization’s  DP  function,  from  its  inception  the  mature  management  of 
data  resources.  The  model  was  originally  conceived  as  a  four  stage  model,  but 
was  modified  to  six  stages  as  a  result  of  the  continued  increase  in  complexity  of 
the  DP  environment.  During  the  first  three  stages,  DP  management  is  concerned 
with  management  of  the  computer.  At  approximately  the  middle  of  stage  three, 
there  is  a  transition  to  management  of  the  data  resource.  (Figure  3)  The  model 
is  a  useful  strategic  IS  planning  tool  in  that  it  provides  management  with  a 
diagnostic  tool  for  identifying  the  current  state  of  the  organization’s  IS  function. 
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STAGE  1  STAGE  2  STAGE  3  STAGE  4  STAGE  5  STAGE  6 

Slow  DP  Growth  Attempts  to  Application  Some  slowing  DP  growth 

growth  speeds  up  introduce  development  of  growth  tracks  the 

as  controls  and  faster  due  due  to  sales  growth 

application  retrofit  t0  ciass  jjj  further  of  the 

development  applications  data  bases  attempts  to  organization 

spreads  slows  DP  integrate 

growth 

INITIATION  CONTAGION  CONTROL  INTEGRATION  DATA  ADMIN.  MATURITY 


Figure  3.  Nolan’s  Stages  of  Growth  [Ref.  9:p.  81] 
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and  what  must  be  accomplished  to  evolve  to  the  next  stages.  According  to  the 
model,  an  organization  starts  at  the  first  stage,  Initiation,  and  must  evolve  through 
every  subsequent  stage  before  reaching  maturity  in  its  DP  function.  The  six 
stages  are  described  below:  [Ref.  9:p.  80] 


1.  Stage  1:  Initiation:  Initial  development  of  an  organization’s  first 
applications-  generally  "back-room",  administrative  and  accounting 
applications.  No  overall  DP  control. 

2.  Stage  2:  Contagion:  Enthusiasm.  Growing  demand  for,  and  proliferation 
of,  applications.  Applications  developed  in  isolation  causing  incompatible 
and  redundant  data.  Lack  of  planning  and  control  mechanisms. 

3.  Stage  3:  Control:  Management  attempting  to  gain  control  of  DP  function 
due  to  user  frustration,  high  maintenance  costs,  and  a  long  applications 
backlog.  Management  upgrades  documentation,  restructures  existing 
applications,  introduces  data  base  management,  and  formalizes  planning  and 
control  mechanisms.  Slow  application  development  as  a  result  of  DP 
rebuilding  and  restructuring.  Perceived  need  for  Data  Administration, 
although  little  action  taken. 

4.  Stage  4:  Integration:  Existing  applications  retrofitted  to  dat2  base 
technology.  Successful  Class  III  data  bases  lead  to  fundamental  changes 
in  applications  development  process.  Increase  in  demand  for  DP. 
Increased  DP  growth  and  expenditure.  Redundancies  of  data  and  lack  of 
enterprise-wide  information  analysis  hinder  attempts  to  develop  planning 
and  control  applications. 

5.  Stage  5:  Data  Administration:  Information  Resource  Management. 
Enterprise-based  strategic  planning  of  the  data  resource.  Stable  data 
models  and  end-user  computing.  Class  I  data  bases  provide  flexible  and 
valuable  IS  and  decision  support  systems. 

6.  Stage  6:  Maturity:  Organization-wide  information  analysis  and  data 
modeling  has  been  implemented.  Applications  mirror  the  enterprise.  DP 
growth  tracks  the  sales  growth  of  the  organization. 
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The  transition  point  in  between  stages  3  and  4  represents  the  point  at 
which  applications  development  should  become  data  base-driven  rather  than 
application-driven.  Further,  systems  analysis  and  design  moves  from  a  procedure 
orientation  to  a  data  orientation. 

Nolan’s  Stage  model  can  be  employed  to  analyze  both  the  organization 
as  a  whole  and  its  individual  business  units.  An  organization  may  have  separate 
divisions  that  simultaneously  reside  in  all  six  stages.  Determining  which  stage  the 
organization  or  business  unit  resides  in  can  be  a  difficult  process.  Figure  4  gives 
a  graphical  representation  of  the  benchmarks  required  to  determine  the  placement 
of  the  organization.  Taking  a  single  benchmark  by  itself  may  be  misleading, 
therefore  management  should  examine  all  six  benchmarks  before  determining  their 
organization’s  stage  of  DP  growth. 

Managing  the  organization’s  evolution  through  each  stage  of  growth  is 
a  key  challenge  for  IS  and  senior  line  management.  Nolan  has  developed  five 
guidelines  for  effectively  managing  and  taking  advantage  of  this  growth. 
[Ref.  10:p.  122]  First,  he  states  that  management  must  recognize  the  transition 
of  the  organization  from  computer  management  to  information  resource 
management.  Managers  must  first  recognize  the  change  and  then  develop  data- 
oriented  applications  and  planning  and  control  systems  to  facilitate  the  transition. 
Second,  management  must  recognize  the  importance  of  new  technologies  that 
enable  the  smooth  transition  to  data  administration.  Third,  management  must 
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Exhibit  V 
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Figure  4.  Benchmarks  of  the  Six  Stages  [Ref.  10:p.  122} 
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identify  the  stage  of  DP  evolution  for  each  business  unit  in  order  to  keep  DP 
activities  on  track.  By  knowing  where  each  unit  stands  in  the  evolution  of  its  DP 
function,  management  can  effectively  plan  for  the  future.  Fourth,  management 
should  develop  a  multilevel  IS  strategy  and  plan.  Nolan’s  Stage  model  provides 
the  first  input  to  the  strategic  planning  process  by  providing  management  with  a 
way  of  determining  their  current  state.  Once  management  knows  where  the 
organization  and  each  business  unit  stands,  they  can  utilize  the  model  to  develop 
an  IS  strategy  and  growth  plan  that  is  aligned  with  the  firm’s  overall  business 
strategy.  Finally,  top  management  must  make  the  executive  steering  committee 
work.  In  order  to  effectively  plan  for  IS,  senior  management  must  formulate  a 
strategy,  set  priorities,  and  establish  a  favorable  environment  for  IS  growth. 

Nolan’s  Stages  of  Growth  model  enables  management  to  determine  the 
most  appropriate  IS  strategy  for  the  organization,  based  on  its  current  stage.  It 
is  also  useful  for  diagnosing  and  understanding  changes  that  must  be  made  to 
facilitate  tne  transition  between  stages.  As  such,  it  represents  an  easy  -to  - 
understand  and  powerful  tool  for  beginning  a  strategic  IS  planning  process.  The 
major  drawback  to  the  model  is  that  it  gives  a  "snapshot"  picture  of  the 
organization  or  business  unit  at  a  given  time,  and  does  not  adequately  show  the 
direction  of  changes.  Similarly,  despite  the  benchmarks  provided  for  determining 
the  stage  of  growth,  it  can  be  extremely  difficult  to  accurately  map  complex 
organizations  such  as  the  DON  into  a  specific  stage. 
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3.  IS  Strategy  Development  and  Analysis 


Once  the  current  stage  of  IS  activity  is  known,  an  analysis  of  the 

strengths  and  weaknesses  that  bear  on  its  IS  strategies  must  be  conducted. 

Internal  factors,  such  as  budgetary  and  human  constraints,  and  external  factors, 

such  as  competition,  legislation,  and  the  prevailing  technological  climate,  must  be 

considered.  It  is  important  to  understand  that: 

...  the  extent  and  complexity  of  corporate  activity  make  it  impossible  for 
data  processing  to  be  ’all  things  to  all  people’.  Consequently,  decisions  will 
have  to  be  made  on  what  data  processing  be  -its  priorities  and  purposes; 
when,  where,  and  whom  it  will  serve;  and  so  on.  If  the  DP  management 
makes  these  decisions  without  the  benefit  of  an  agreed-upon  strategy  and 
plan,  the  decisions  are  apt  to  be  wrong,  if  they  are  right,  the  rationale  for 
them  will  not  be  adequately  understood  by  users  (and  management).  If 
users  do  not  understand  the  strategic  direction  of  data  processing,  they  are 
unlikely  to  provide  support.  [Ref.  10:p.  126] 

Next,  management  must  develop  an  IS  strategic  plan  that  fulfills  the 
information  requirements  of  the  organization,  and  formulate  policies  with  which 
to  implement  this  strategy.  As  stated  earlier,  this  IS  strategy  must  be  an  integral 
part  of  the  overall  business  plan  to  achieve  the  optimum  match  between  the 
organization’s  information  requirements  and  the  functioning  of  its  IS  component. 

The  tactical  planning  phase  is  concerned  with  long  and  medium  range 
(2-10  years)  conceptual  planning,  and  the  development  and  formulation  of  the  IS 
Master  Plan.  The  IS  Master  Plan  starts  with  needs,  objectives,  and  constraints  set 
forth  in  the  strategic  plan,  and  entails  the  following: 
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1.  Requirements  analysis; 

2.  Assembly  of  an  applications  portfolio; 

3.  Establishment  of  a  priority  scheme  for  the  applications  portfolio; 

4.  Development  of  applicable  information  systems  architectures.  [Ref.  7:p.  4] 

In  addition,  it  documents  plans  and  policies  for  non-ADP  support  activities  such 
as  procurement  or  logistics.  The  IS  architectures  developed  are  graphical 
statements  of  flows,  interfaces,  and  information,  technical,  and  support 
requirements  that  illustrate  how  individual  systems  and  components  fit  together 
to  form  an  integrated  comprehensive  whole.  Management  must  develop  IS 
architectures  that  establish  goals  and  strategies  for  each  IS  function  in  order  to 
make  them  fully  supportive  of  the  overall  business  plan.  The  following 
architectures  should  be  developed:  data,  information  flow,  technical,  support 
systems,  network,  and  any  other  applicable  functions.  Each  architecture  should 
illustrate: 

1.  the  current  or  baseline  situation; 

2.  the  planned  or  interim  situation  when  all  currently  programmed  actions 
are  implemented; 

3.  the  target  situation.  [Ref.  ll:p.  2] 

Each  architecture  study  will  assist  the  planner  in  the  refinement  of  the 
organization’s  IS  objectives.  Without  a  solid  grasp  of  how  the  goals  of  the 
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organization  are  translated  into  these  architectures,  application  development  efforts 
will  have  a  short  term  perspective  resulting  in  the  development  of  isolated, 
fragmented  systems  that  do  not  meet  the  overall  needs  of  the  organization.  This 
problem  is  particularly  evident  in  large,  complex  DON  organizations,  such  as  those 
at  the  SYSCOM  and  TYCOM  level.  (Figure  5)  IS  architectures  serve  "as  a 
blueprint  on  which  systems  development  activities  can  be:  a)  prioritized  by 
deciding  the  sequencing  for  building  the  architecture;  b)  coordinated  by  relating 
to  other  systems  in  an  efficient  manner;  and  c)  optimized  by  building  each  system 
with  the  corporate  information  requirements  in  mind."  [Ref.  2:p.  204] 

There  is  significant  volatility  in  the  IS  environment  due  to  technological 
innovation,  competition,  changes  in  corporate  strategies,  and  many  other  factors. 
This  volatility  places  a  premium  on  the  successful  development  of  flexible  Master 
plan  and  architectures  that  will  permit  orderly  and  consistent  change  to  match 
evolving  organizational  requirements. 

The  operational  IS  planning  phase  involves  the  development  of  a 
detailed  annual  IS  plan.  This  plan  should  include  performance  targets,  resource 
allocation  and  budgetary  decisions,  specific  tasks  and  schedules,  and  other 
activities  required  for  achieving  short  range  objectives.  [Ref.  7:p.  5]  The  annual 
plan  should  be  based  on  the  broader  objectives  set  forth  in  the  Master  Plan,  in 
order  to  maintain  a  linkage  between  the  day-to-day  operation  of  the  IS  activity, 
and  the  strategic  and  tactical  objectives  of  the  organization. 
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C.  METHODOLOGIES  FOR  LINKING  STRATEGIC  AND  IS 

PLANNING 

1.  Maintenance  Hassles  Drive  the  Need  For  a  New  Approach 

The  maintenance  of  systems  developed  using  traditional  manual 
approaches  such  as  Structured  Analysis  and  Design  is  extremely  high.  The  cost 
of  this  maintenance  may  add  up  to  as  much  as  four  times  the  development  cost 
over  the  life  of  the  project.  In  addition,  it  may  absorb  some  60-80  percent  of 
analyst  and  programmer  resources,  leaving  only  the  remainder  for  the 
development  of  new  systems.  One  of  the  primary  reasons  for  these  maintenance 
problems  is  the  fact  that  these  systems  have  traditionally  been  developed  to  meet 
narrow  management  needs,  without  regard  for  the  strategic  objectives  of  the 
organization.  In  addition,  since  the  systems  were  developed  using  process-oriented 
techniques,  they  are  highly  susceptible  to  environmental  pressures,  and  changes  in 
management  information  requirements. 

IBM  realized  this  problem,  and  developed  Business  Systems  Planning 
(BSP)  as  a  potential  solution.  [Ref.  13:p.  43]  James  Martin  and  Clive  Finkelstein 
followed  with  the  introduction  of  Information  Engineering.  [Ref.  9:p.  4]  Both 
methodologies  are  data-oriented,  and  are  based  on  a  solid  foundation  of  strategic 
planning.  In  addition,  both  accelerated  systems  development  time,  and  had  a 
significant  positive  impact  on  maintenance  costs. 
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2.  Information  Engineering 


a.  Overview 

Information  Engineering  (IE)  was  introduced  by  James  Martin  and 
Clive  Finkelstein  in  the  1970’s.  [Ref.  9:p.  2]  It  represents  the  compilation  of  an 
interrelated  set  of  disciplines  required  to  build  enterprise-based  computerized 
information  systems.  In  contrast  to  software  engineering  and  structured  analysis 
and  design  approaches,  IE  is  specifically  designed  to  draw  on  the  strengths  of  the 
user,  management,  and  DP  personnel  throughout  the  system  development  process. 
It  is  a  data-oriented  approach,  and  is  based  on  the  premise  that  data  and 
information  are  two  of  the  primary  resources  of  an  organization,  and  lie  at  the 
center  of  modern  data  processing.  This  data-oriented  approach  provides  a  solid 
foundation  on  which  to  build  computer  systems,  because  the  structure  of  data 
does  not  change;  the  processes  that  use  it  do.  IE  provides  the  means  to  develop 
the  "one  and  only  one  minimal  nonredundant  structure  of  the  data,"  and  this 
structure  forms  the  foundation  on  which  information  systems  can  be  built. 
[Ref.  9:p.  4]  In  addition,  IE  enables  rapid  response  to  the  changing  information 
needs  of  management,  because  procedures  are  able  to  be  changed  quickly  because 
they  are  independent  of  the  data.  Procedure  or  process-oriented  techniques,  on 
the  other  hand,  tend  to  produce  systems  that  are  difficult  to  implement  in  a 
timely  manner,  and  which  are  unresponsive  to  changing  requirements.  Since  they 
build  systems  based  on  the  processes  of  an  organization,  they  are  subject  to  the 


28 


inherent  instability  and  dynamic  nature  of  those  procedures.  The  goal  of  IE  is 
to  provide  the  means  to  fulfill  management’s  requirements  for  information  rapidly 
and  effectively,  and  to  act  as  the  primary  implementation  vehicle  for  achieving 
Information  Resource  Management  (IRM). 

b.  Methodology 

Information  Engineering  facilitates  strategic  systems  development 
through  the  use  of  modeling.  It  models  the  organization  in  terms  of  its  data 
resource,  (data  that  is  fundamental  to  the  enterprise)  and  the  policies,  objectives, 
and  strategies  developed  by  management.  The  data  model  is  based  on  the 
premise  that  the  data  used  in  an  organization  does  not  change  significantly,  while 
the  procedures  that  use  it  will.  The  banking  industry  is  an  excellent  example  of 
this  premise.  The  procedures  for  personal  banking  have  changed  dramatically 
over  the  years,  however  the  data  behind  them  (deposit,  withdrawal,  and  balance 
data)  have  remained  essentially  unchanged.  Data  changes  only  as  the  business 
itself  changes.  With  an  accurate  data  model,  the  organization  can  represent  itself- 
its  business,  its  products  and  services,  and  its  markets  -  in  terms  of  its  data.  As 
such,  the  data  model  is  the  blueprint  of  the  organization,  and  represents  an 
effective  tool  for  management  to  develop  and  evaluate  different  policies, 
objectives,  and  strategies. 

There  are  nine  basic  building  blocks  defined  in  IE.  Each  of  which 
is  highly  dependent  on  the  one  beneath  it.  (Figure  6)  The  first  block.  Strategic 
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Requirements  Analysis,  is  the  foundation  for  the  success  of  the  methodology,  but 
unfortunately,  it  is  often  overlooked.  It  attempts  to  identify  the  objectives  of  the 
organization,  and  what  information  is  needed  for  enabling  it  to  accomplish  these 
objectives.  The  next  block.  Information  Analysis,  comprises  a  top-down  analysis 
of  the  types  of  data  that  must  be  kept  by  the  organization,  and  how  they 
interrelate.  Identifying  these  data  types  is  critical  because  of  the  premise  that 
data  structures  must  remain  stable.  In  the  third  stage,  Data  Modeling,  the 
detailed  logical  data  base  design  is  created.  Here,  it  is  critical  that  the  data  be 
structured  independent  of  the  processes  that  will  use  it.  The  fourth  block. 
Procedure  Formulation,  identifies  events  that  change  or  use  the  data  base.  These 
procedures  ideally  should  be  designed  by  users,  possibly  with  the  aid  of  fourth 
generation  languages  and  application  generators.  Block  five,  Data  Use  Analysis, 
and  block  six.  Distribution  Analysis,  prepare  the  logical  data  model  for  conversion 
of  the  data  models  and  procedures  into  the  physical  data  base  design 
accomplished  in  block  seven.  Block  eight.  Program  Specification  Synthesis,  merges 
the  different  procedures,  documents  data  changes,  and  produces  functionally 
cohesive  program  code.  Finally,  block  nine,  Application  Development  Without 
Programmers,  represents  the  ability  of  users  to  develop  their  own  applications 
through  the  use  of  uon  procedural  languages  and  capabilities. 
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c.  Assessment  of  Information  Engineering 

The  stability  of  data  models  achieved  through  the  use  of  IE  is  a 
major  selling  point,  in  that  it  allows  for  the  creation  of  flexible,  objectives-driven 
systems  that  meet  the  current  and  future  information  needs  of  an  organization. 
Further,  the  use  of  modeling  techniques  throughout  the  IE  lifecycle,  provides  for 
rapid  feedback  for  strategic  management.  Modeling  allows  management  to 
quickly  consider  the  implications  of  alternative  strategies.  Additionally,  the  IE 
lifecycle  is  an  evolutionary  process  whose  formal  steps  progressively  expand  and 
enrich  the  data  model  and  its  strategies.  Finally,  and  most  important,  Information 
Engineering  is  user-driven.  It  draws  on  the  expertise  of  users  throughout  the 
organization.  They  design  the  data  model;  they  design  the  system;  and  they 
identify  the  data  and  information  needed  by  management  for  decision-making. 
The  user  intensity  of  IE  is  one  of  its  primary  drawbacks  in  real-world 
applications.  IE  requires  a  large  up  front  commitment  from  users  and 
management  in  order  to  provide  a  solid  strategic  and  conceptual  foundation  for 
systems  development.  Without  this  commitment,  the  benefits  of  utilizing  IE 
cannot  be  fully  realized.  Further,  it  assumes  that  users  and  management 
understand  their  business  and  the  methodology;  neither  of  which  are  safe 
assumptions.  Thus,  training  in  both  areas  should  be  a  prerequisite  of  an  IE 
project  to  ensure  that  the  conceptualization  of  the  data  model  is  accurate. 
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3.  IBM’s  Business  Systems  Planning  (BSP) 

a.  Overview 

BSP  is  a  planning  methodology  that  has  been  offered  as  a  market 
support  program  by  IBM  since  the  early  1970’s.  It  was  developed  from 
knowledge  acquired  from  an  internal  study,  the  IBM  Corporate  Information 
Systems  Architecture  group,  in  the  late  1960’s.  [Ref.  13:p.  48]  BSP  stresses  "top- 
down"  enterprise  analysis,  and  an  implementation  strategy  where  information 
support  is  implemented  in  a  modular  fashion  over  time.  This  ensures  that  the 
implementation  remains  consistent  with  organizational  business  priorities,  available 
funds,  and  other  shorter-term  considerations. 

Several  steps  are  involved  in  a  BSP  analysis.  The  first  step 
involves  establishing  the  study  scope,  selecting  the  study  team,  and  defining 
business  objectives.  The  next  step  is  to  define  business  processes  and  then 
business  data.  Data  definition  is  accomplished  by  identifying  critical  business 
entities  and  the  data  required  to  manage  them.  Finally,  an  information 
architecture,  the  statement  of  long-term  IS  objectives,  is  defined,  reviewed  by  top 
management,  and  released.  Designer/analysts  will  use  this  information 
architecture  in  the  future  to  build  enterprise-based  information  systems. 


33 


b.  Methodology 

As  with  Information  Engineering,  the  success  of  a  BSP  study  is 
highly  dependent  on  top  management  involvement.  As  such,  an  assessment  of  the 
degree  of  commitment  of  the  organization  to  the  study  should  be  conducted  prior 
to  commencement  of  the  study.  Alter  this  assessment,  the  project  team  should 
be  selected  from  key  management  personnel  with  expert  knowledge  of  the 
enterprise  and  its  functions.  Once  this  is  complete,  the  project  team  will  attempt 
to  identify  and  set  objectives  for  the  organization,  and  then  establish  a  scope  for 
the  project.  This  project  scope  can  target  a  specific  area  of  the  organization,  or 
cover  its  entire  span. 

Businesses  whose  activities  span  multiple  functional  units  tend  to  gain  more 
from  a  BSP  study  than  those  that  are  more  simply  structured  since  BSP 
deals  well  with  complexity.  It  is  designed  to  identify  the  requirements  for 
data  integration  across  multiple  functions.  [Ref.  14:p.  14] 

Once  the  above  issues  have  been  dealt  with,  the  project  team  must 
select  and  schedule  specific  personnel  to  be  interviewed,  develop  a  master  plan 
for  the  study,  and  establish  administrative  support  for  the  project.  Finally,  a  start¬ 
up  meeting,  attended  by  the  project  team,  key  management,  and  other  pertinent 
personnel,  should  be  conducted  to  "kick-off"  the  study. 

The  first  step  in  the  actual  BSP  study  process  is  the  definition  of 
business  processes.  Business  processes  are  groups  of  logically  related  decisions 
and  activities  required  to  manage  organizational  resources.  In  order  to  accomplish 
this  step,  the  project  team  must  first  identify  the  products  or  services  output  by 
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the  organization,  and  its  supporting  resources,  such  as  raw  materials,  capital, 
personnel,  and  facilities.  Next,  business  processes  relating  to  these  items  are 
identified.  There  may  be  multiple  processes  for  each  one.  This  initial  list  of 
processes  is  then  pared  down,  grouped,  and  prioritized  to  reduce  inconsistencies 
and  redundancies.  Finally,  these  products  must  be  related  to  organizational  units. 
This  is  accomplished  through  the  development  of  Process/Organization  Matrix. 
This  matrix  graphically  illustrates  the  degree  of  involvement  of  the  various 
organizational  units  in  each  business  process.  (Figure  7)  There  are  four  possible 
degrees  of  involvement:  major  responsibility  and  decision  maker  (X),  major 
involvement  (X),  some  involvement  (/),and  no  involvement  (blank). 

After  all  business  processes  have  been  defined,  the  project  team 
must  identify  and  define  business  entities,  data  classes,  and  the  relationship 
between  the  two.  A  business  entity  can  be  a  person,  place,  or  thing,  or  any 
pertinent  item  about  which  data  can  be  collected  or  stored.  Their  identification 
serves  as  a  basis  for  determining  the  data  needs  of  the  organization.  Each 
business  entity  should  be  broken  down  to  where  it  can  be  uniquely  identified,  and 
carefully  described.  Next,  the  business  entities  are  clarified  and  refined  by 
determining  data  needs,  their  related  business  processes,  and  the  relationship  of 
both  to  the  specific  entities.  Determination  of  the  relationship  of  data  to 
processes  allows  the  project  team  to  identify  data  classes:  a  category  of 
information  about  a  specific  entity.  Finally,  each  data  class  is  refined  and 
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described  completely.  There  must  be  no  more  than  one  source  for  each  data 
class  in  order  to  ensure  data  integrity. 

After  all  data  classes  are  defined,  the  relationship  between  data 
classes  and  business  processes  is  established  through  the  formulation  of  the 
Information  Architecture  (Process/Data  Gass  Matrix).  (Figure  8)  There  are  three 
types  of  relationships  represented  in  the  matrix:  creation  (C),  where  the  process 
creates  the  data  class;  usage  (U),  where  the  process  uses  the  data  class;  and  no 
involvement  (blank).  The  groupings  resulting  from  this  matrix  can  then  be  related 
to  organizational  personnel  and  structure.  This  gives  the  organization  a  logical 
view  of  who  needs  and  uses  specific  data  and  information,  and  in  what  processes 
they  use  them.  Finally,  data  flows  between  processes  are  identified,  by  relating 
processes  that  create  data  classes  and  those  that  use  them.  Arrows  are  drawn 
between  the  two  to  create  a  flow  chart  of  data  through  the  organization.  The 
resulting  information  architecture  is  the  key  deliverable  of  a  BSP  study.  It 
illustrates  information  flow  throughout  the  organization,  and  relationships  between 
processes  and  entities.  Further,  it  provides  management  with  the  following 
pertinent  information:  [Ref.  14:p.  45] 

1.  The  project  team’s  recommendation  for  long  range  IS  implementation. 

2.  The  information  systems,  represented  by  the  blocks  or  boxes,  that  form  the 
long  range  plan. 

3.  The  data  controlled  by  each  information  system,  (read  vertically) 
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4.  The  business  processes  supported  by  each  information  system,  (read 
horizontally) 

5.  The  flow  of  information  between  the  various  information  systems,  (lines 
and  arrows)  and  thus  the  flow  of  information  through  the  business  itself. 

From  these  results,  management  can  determine  their  current  level  of  IS  support, 
determine  organizational  IS  priorities,  and  decide  on  current  and  future 
information  resource  strategy. 

c.  Assessment  of  Business  Systems  Planning 

BSP  was  the  first  methodology  to  recognize  and  emphasize  data  as 
a  corporate  resource.  As  such,  it  emphasizes  the  fundamental  need  for  top 
management  involvement  in  the  IS  planning  process.  It  helps  establish  lines  of 
communication  between  users,  top  management,  and  data  processing  personnel, 
and  confronts  management  with  the  importance  of  dealing  with  DP  issues  on  an 
organizational  level.  Further,  it  develops  an  enterprise-level  information 
architecture,  and  "objectively  deals  with  the  priority  issue,  identifying  areas  in 
which  the  information  system  resource  can  best  be  invested  for  the  overall 
interest  of  the  business  at  a  given  point  in  time."  [Ref.  13:p.  49]  Finally,  it  is 
a  well  documented  methodology,  it  is  widely  used,  and  it  is  widely  understood. 
[Ref.  13:p.  49]  There  are  several  key  weaknesses  apparent  in  the  BSP  approach. 
First,  since  the  entire  process  is  based  on  creative  analysis  and  individual 
interviews  by  the  project  team,  it’s  quality  is  highly  dependent  on  the  team’s 


understanding  of  what  they  are  looking  for,  where  they  will  find  it,  and  how  to 
document  it.  Second,  the  structure  developed  is  highly  customized,  with  limited 
transferability  or  comparability  to  other  study’s  structures.  Third,  the  BSP  study 
process  is  a  time-consuming  and  cumbersome  process,  that  really  only 
encompasses  the  planning,  organizational  analysis,  and  requirements  analysis 
phases  of  the  systems  lifecycle.  In  addition,  it  is  extremely  difficult  to  bridge 
between  the  planning  activity  of  the  study  and  systems  implementation.  The 
deliverables  of  the  process,  the  matrices  and  displays,  are  difficult  to  update,  and 
provide  no  basis  for  the  system’s  design.  As  such,  systems  developers  must  take 
the  product  of  a  BSP  study  and  then  revert  back  to  traditional  system 
development  techniques.  This  just  adds  more  unnecessary  time  constraints  to  the 
development  process.  Recently,  CASE  tools  such  as  KnowledgeWare’s  IEW  have 
automated  portions  of  the  BSP  process,  speeding  it  up,  but  many  of  the 
weaknesses  discussed  remain. 

4.  Comparison  of  Information  Engineering  and  BSP 

Both  Information  Engineering  and  Business  Systems  Planning  are  data- 
oriented,  and  both  recognize  the  importance  of  linking  information  systems 
planning  to  the  strategic  objectives  of  the  organization.  In  addition,  both 
methodologies  are  widely  used  and  well  documented.  However,  Information 
engineering  provides  significant  benefits  to  the  organization  relative  to  BSP. 
First,  IE  provides  a  set  of  interrelated  systems  development  techniques  that  span 
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the  entire  systems  lifecycle,  from  strategic  planning  to  full  systems  implementation. 
On  the  other  hand,  BSP  only  provides  techniques  for  organizational  analysis  and 
strategy-to-requirements  transformation.  It  does  not  provide  full  lifecycle  support. 
Second,  IE  is  a  user-driven  methodology,  whereas  BSP  is  essentially  analyst-driven. 
In  an  IE  project,  users  are  fully  involved  in  the  development  of  the  data  models, 
and  throughout  subsequent  phases  of  development.  BSP  studies  utilize  personal 
interviews  to  glean  information  requirements;  construction  of  the  Information 
Architecture  is  accomplished  by  analysts.  Third,  whereas  IE  supports  systems 
development  through  implementation,  the  deliverables  of  the  BSP  process  are 
difficult  to  update,  and  provide  no  basis  for  system  design.  As  a  result,  the  IE 
process  is  considerably  faster  over  the  same  lifecycle  phases  than  BSP;  a  vital 
consideration  in  today’s  IS  climate. 
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III.  INFORMATION  RESOURCE  PLANNING  IN  THE  DEPARTMENT  OF 

THE  NAVY 

A.  THE  DEPARTMENT  OF  THE  NAVY’S  IR  PLANNING  PROCESS 
The  IS  planning  program  in  the  Department  of  the  Navy  is  a  multi-level 
program  that  seeks  to  develop  an  integrated  approach  and  overall  framework  for 
meeting  its  overall  information  requirements.  It  attempts  to  align  IS  planning  at 
all  levels  to  the  overall  strategic  objectives  of  the  organization.  SECNAV 
Instruction  5230.10,  the  DON  Strategic  Plan  for  Managing  Information -and 
Related  Resources  (IRSTRATPLAN),  provides  a  top-down  perspective  of  DON 
information  resources  as  they  relate  to  both  tactical  and  administrative  functions. 
In  addition,  it  provides  strategies,  policies,  and  guidance,  on  which  DON 
commands  can  base  their  IR  planning  and  management  efforts.  SECNAV 
Instruction  5230.9A,  the  Information  Resources  (IR)  Program  Planning  guide, 
provides  top-down  IR  planning  guidance  to  DON  organizations  at  the 
departmental,  functional  sponsor,  and  component  levels.  Both  documents  provide 
a  broad  foundation  on  which  to  structure  DON  IR  planning  efforts. 

The  DON  IR  planning  program  is  a  continuous  process  that  includes  both 
strategic  IR  planning  and  IR  requirements  planning.  Strategic  IR  planning 
requires  an  analysis  of  the  information  support  environment  internal  to  the  DON 
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and  an  assessment  of  the  impact  of  external  factors  such  as  technology  trends, 
competition,  and  politics.  Top  management  derives  high  level  IS  policies  and 
strategies  from  this  analysis,  and  these  provide  the  basis  for  IR  planning  at  all 
subordinate  levels.  Results  of  the  strategic  IR  planning  process  are  documented 
in  the  DON  Strategic  Plan  For  Information  Systems  Management.  [Ref.  ll:p.  5] 

The  objective  of  DON  IR  requirements  planning  is  to  analyze  major 
organizational  functions,  derive  their  information  requirements,  and  coordinate  the 
requirements  with  the  strategic  directions  and  policies  promulgated  in  the  strategic 
plan.  Both  current  and  future  information  requirements  are  assessed,  and  any 
shortfalls  in  satisfying  those  requirements  are  identified.  The  information 
requirements  derived  form  the  basis  for  project  selection  downstream  at  the 
activity  level. 

The  DON  IR  requirements  planning  process  begins  in  January  at  the 
Departmental  level,  and  continues  through  April.  (Figure  9)  In  January, 
departmental  level  functional  sponsors  document  DON-wide  requirements  for  IR 
support  needed  in  major  functional  areas  such  as  Manpower,  Supply,  or  Safety. 
These  requirements  are  documented  in  Functional  Area  Strategic  Plans  (FASP). 
FASP’s  were  previously  called  Functional  Sponsor  Plans.  In  February,  the  FASP’s 
are  reviewed  by  the  IR  Planning  Committee  to  ensure  "appropriate  interfaces  and 
integration  between  functional  area  planning."  [Ref.  ll:p.  6]  The  IR  Planning 
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Committee  should  consist  of  high-level  members  from  commands  at  the 
departmental  and  component  level,  such  as  the  Director,  Naval  Supply  Systems 
Command,  or  the  various  Deputy  Chiefs  of  Naval  Operation.  The  FASP’s  are 
submitted  to  the  Director,  DON  Information  Resource  Management 
(DIRDONIRM)  in  March.  They  are  presented  at  the  Functional  Area  strategic 
planning  conference,  also  in  March,  and  are  distributed  to  the  cognizant 
component  commands.  The  results  of  IR  planning  at  this  level  are  documented 
In  the  DON  Information  Management  Plan  (IMP)  released  in  June. 

IR  planning  occurs  at  the  component  level  from  April  until  July. 
Component  level  IR  planning  "develops  a  framework  for  IR  support  within  the 
component  headquarters  and  all  subordinate  organizations.  Emphasis  is  on 
supporting  the  component’s  mission  and  functions  within  the  context  established 
by  departmental  strategic  and  long-range  plans."  [Ref.  ll:p.  6]  The  results  of  the 
component  level  IR  planning  process  are  documented  in  Component  Information 
Management  Plans  (CIMP).  In  mid- August,  the  CIMP’s  are  presented  to  the  IR 
Planning  Committee  at  the  annual  IR  Planning  Conference.  Each  CIMP  is  then 
distributed  to  all  organizations  having  a  funding  or  other  management 
responsibility  for  planned  actions. 

Throughout  the  rest  of  the  year,  IR  planning  and  management  occurs  at  the 
cognizant  activity  level  in  accordance  with  the  Planning,  Programming  and 
Budgeting  System  (PPBS)  and  Life  Cycle  Management  (LCM)  processes.  The 
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objectives  promulgated  in  the  CIMP  or  FASP  will,  if  approved  for  development 
or  acquisition,  be  further  refined  in  project  plans,  which  in  turn,  form  the  basis 
for  initiating  the  LCM  process. 

B.  ASSESSMENT  OF  DON  IR  PLANNING  PROCESS 

On  paper,  the  DON  IR  planning  program  appears  to  be  comprehensive  and 
effective.  On  the  other  hand,  several  habitual  internal  management  problems 
continue  to  hinder  these  efforts.  First,  top  DON  management,  including  IS 
management,  suffers  from  an  insufficient  level  of  expertise  on  key  computer- 
related  issues.  Misperceptions  as  to  what  Information  Resource  Management  is, 
why  it  is  required,  and  what  organizational  structure  is  required  to  accomplish  it, 
cause  a  lack  of  direction  concerning  IR  planning  at  top  DON  IS  management 
levels.  This  manifests  itself  in  a  deficiency  of  specific  top-down  guidance  from 
DIRDONIRM  and  NAVDAC,  which  hampers  the  annual  planning  efforts  of 
subordinate  levels.  The  key  to  successful  IR  planning  at  all  levels  is  for  top 
management  to  "clearly  define  at  any  point  in  time  exactly  those  factors  that  are 
crucial  to  the  success  of  his  particular  organization  in  the  period  for  which  he  is 
planning."  [Ref.  15:p.  127]  Similarly,  NAVDAC  and  the  DONIRM  staff  have 
been  unable  to  provide  the  assistance  and  training  required  by  component  and 
subordinate  activities  to  build  their  own  IR  planning  staffs.  Their  lack  of 
expertise  on  IRM-related  issues  prevents  them  from  providing  the  proactive 
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leadership  required  for  effective  IR  planning,  and  limits  them  to  a  review  role  in 
the  planning  process.  The  ability  to  provide  detailed  critiques  of  the  CIMP’s  and 
FASP’s,  and  to  ask  hard,  probing  questions  of  both  components  and  resource 
sponsors,  is  vital  to  effectively  manage  the  DON  IR  planning  effort.  In  order  to 
reach  the  knowledge  level  required  for  effective  management  of  the  IR  planning 
process,  a  comprehensive  education  program  on  IRM  and  IR  planning  issues 
should  be  established.  The  training  program  should  reach  all  personnel  with 
management  and  funding  responsibility  in  this  arena,  and  cover  all  facets  of 
Information  Resource  Management  including  planning  and  Data  Administration 
issues,  and  strategic  development  methodologies  such  as  Information  Engineering. 
A  related  issue  which  has  adversely  affected  the  effectiveness  of  IR  planning  and 
IRM,  is  the  shortage  of  computer-literate  officers  at  all  levels,  resulting  from  the 
failure  to  create  a  competitive  career  path  in  this  area.  The  failure  to  effectively 
utilize  officers  with  Masters-level  education  in  Computer  Systems  Management, 
Telecommunications,  and  Computer  Science,  has  created  a  significant  management 
void  in  these  fields,  and  an  important  barrier  to  effective  IR  planning.  A  second 
internal  factor  hindering  the  IR  planning  process  has  been  the  lack  of 
commitment  to  the  process  by  top  management  at  the  resource  sponsor  and 
component  levels.  This  is  evidenced  by  their  attendance  record  at  the  annual 
planning  conferences,  and  their  level  of  participation  at  the  meetings.  Generally, 
the  senior  managers  attend  the  conferences  for  their  briefs  only,  and  then  turn 
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over  responsibility  for  attendance  to  second  tier  management.  Second  tier 
management  is  usually  only  interested  in  what  DIRDONIRM  has  to  say,  and  not 
on  broader  issues  that  may  influence  planning  at  their  organization.  In  addition, 
they  are  generally  unprepared,  and  are  incapable  of  asking  or  answering  important 
questions.  As  a  result,  integration  issues  are  not  discussed,  and  therefore  not 
planned  for  at  subordinate  levels.  This  lack  of  top  management  commitment  is 
partially  due  to  their  lack  of  ease  regarding  IRM  issues,  but  also  to 
misperceptions  as  to  the  strategic  importance  of  the  information  or  data  resource 
to  the  organization.  They  see  no  immediate  benefits  from  their  efforts,  and  as 
such,  view  the  IR  planning  process  as  a  significant  resource  drain  and  paperwork 
hassle.  Further,  due  to  the  current  budget  climate,  top  management  commitment 
is  driven  by  cost  considerations,  and  therefore,  is  not  focused  on  long  range 
planning  issues. 

Other  internal  factors  affecting  IR  planning  in  the  Department  of  the  Navy 
are  the  result  of  deficiencies  in  the  process  or  the  documentation  that  governs  it. 
First,  the  IRSTRATPLAN  has  been  updated  three  times  since  its  inception  in 
1987.  The  document  has  developed  into  a  forum  for  top  DON  management  to 
react  to  changing  information  requirements,  and  therefore  is  contradictory  to  what 
the  document  should  be  accomplishing.  The  IRSTRATPLAN  should  serve  as  an 
IS  Master  plan  with  a  five  to  ten  year  planning  horizon.  It  should  be  a  forward 
thinking  and  proactive  document  that  serves  as  the  foundation  for  IR  planning. 
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and  should  not  be  updated  or  modified  on  an  annual  basis.  It  should  only  be 
updated  as  major  changes  in  technology  or  in  the  various  missions  and  objectives 
of  the  Navy  occur.  Second,  the  functional  sponsor  planning  process  has  been 
yielding  information  requirements  and  policies  that  fail  to  provide  an  integrated 
view  of  what  must  be  accomplished  at  the  component  level  to  meet  their  needs. 
This  is  due  to  two  reasons.  First,  in  most  cases,  the  Functional  Area  Strategic 
Plans  are  being  written  by  the  Systems  Commands  (SYSCOM)  or  components 
acting  as  Central  Design  Agencies  (CDA),  that  are  to  use  them  as  a  basis  for 
their  own  planning  process.  As  a  result,  they  don’t  correlate  plans  and  budgets 
well,  and  worse,  they  fail  to  address  broad  issues  such  as  standardization  and 
integration.  Second,  the  SYSCOM’s  and  CDA’s  tend  to  write  the  FASP’s  and 
CIMP’s  in  a  manner  that  justifies  their  own  existence.  Since  they  are  writing 
their  own  planning  guidance,  there  is  no  top-down  pressure  to  streamline  or 
improve  the  planning  and  development  processes  in  their  organizations.  Finally, 
the  DON  IR  planning  process  is  hindered  by  significant  time  constraints. 
Requirements  planning  at  the  functional  sponsor  level  is  constrained  to  three 
months,  while  the  more  comprehensive  component  planning  process  is  limited  to 
two  months.  These  are  highly  unrealistic  constraints  for  effective  planning  and 
policy  making.  However,  since  the  FASP’s  are  written  in  large  part  by 
component  level  organizations,  and  since  the  requirements  and  policies  they 
document  are  relatively  static,  it  is  recommended  that  the  functional  area  strategic 
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planning  process  be  limited  or  done  away  with.  By  doing  so,  the  importance  of 
the  IRSTRATPLAN  as  a  strategic  and  tactical  planning  document  would  be 
increased,  as  would  the  length  of  time  devoted  to  IR  planning  at  the  component 
level.  IR  Planning  in  the  Department  of  the  Navy  has  been  hindered  by  two 
external  factors  as  well:  today’s  unstable  budget  climate,  and  inefficiencies  in  the 
life  Cycle  Management  (LCM)  process.  As  a  result  of  today's  highly  unstable 
budget  climate,  and  the  significant  cuts  in  funding  for  ADP  that  have  been 
incurred  by  the  Department  of  Defense,  IR  planning  currently  involves  running 
from  budget  issues.  Planning  has  become  resource-driven  in  that  it  is  aimed  at 
protecting  what  resources  and  funding  assets  that  have  already  been  accumulated. 
In  addition,  vertical  cuts  and  temporary  scalebacks  in  programs  have  made  it 
impossible  for  management  to  develop  systems  in  accordance  with  their  plans. 
Finally,  budget  constraints  have  adversely  affected  DON  efforts  to  establish 
standards.  The  inability  to  establish  DON-wide  standards  will  hinder  any  efforts 
to  implement  Administration,  or  to  move  towards  an  integrated  overall  IS 
architecture. 

The  second  external  factor  hindering  DON  IR  planning  efforts  is  the 
inefficiency  of  the  Life  Cycle  Management  process  when  applied  to  ADP 
acquisition  and  development.  The  process  affects  IR  planning  and  management 
by  significantly  slowing  down  the  process  of  procurement  and  development  of  IS 
resources.  Continual  budget  justification  at  each  milestone  of  the  process  make 
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the  IS  plan  difficult  to  execute  as  envisioned,  and  mires  the  project  manager  in 
a  continuous  paperwork  nightmare.  Each  LCM  milestone  should  signal  the 
transition  to  the  next  stage  in  the  development  of  the  program,  but  due  to 
continual  budgetary  second  guessing,  the  process  has  become  a  continuous  string 
of  milestones,  none  of  which  move  the  project  ahead.  The  only  ways  to  solve 
this  problem  are  to  grant  the  project  manager  with  increased  authority, 
accountability,  and  time  in  position  to  allow  himself  to  make  procurement 
decisions,  to  significantly  accelerate  the  development  process  through  the 
employment  of  CASE  technology,  or  to  alter  the  LCM  process. 

In  its  present  configuration,  the  LCM  process  is  geared  towards  multiple 
year  systems  development  processes.  The  availability  and  desirability  of 
progressive  systems  development  methodologies  such  as  Information  Engineering 
make  the  requirement  for  a  modified  LCM  process  for  ADP  vital.  The  ability 
of  Information  Engineering  to  accelerate  the  entire  systems  lifecycle  will  be 
defeated  by  the  continual  budget  justifications  required  by  the  current  LCM 
process.  Total  lifecycle  approval  should  be  given  up  front  for  a  program  utilizing 
Information  Engineering,  as  this  would  facilitate  a  total  commitment,  with  all 
required  resources,  to  the  IE  process.  Deferring  reevaluation  of  the  program  until 
System  Decision  Paper  (SDP)  IV  at  approximately  the  two  year  point  would  be 
optimal. 
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C.  CORPORATE  INFORMATION  MANAGEMENT  (CIM) 

The  Corporate  Information  Management  (CIM)  initiative  was  launched  by 
DoD  Comptroller  Atwood  on  4  OCT  89  in  response  to  problems  found  in  the 
recent  Defense  Management  Review  (DMR).  The  initiative  represents  a  move 
to  consolidate  and  standardize  DoD  information  systems  development  and 
management.  Specifically,  the  CIM  initiative  calls  for  the  following: 

1.  Implementation  of  DoD-standard  information  systems  in  six  functional 
areas:  Civilian  Personnel,  Pay,  Inventory  Management,  Warehousing, 
Accounting,  and  Contracting  by  1995. 

2.  Immediate  freeze  on  new  systems,  and  spending  on  systems  under 
development  in  the  above  functional  areas. 

A  separate  but  related  issue,  prompted  also  by  the  DMR,  is  the  consolidation  of 
Central  Design  Agencies  (CDA)  and  Data  Processing  Installations  (DPI)  into  tri¬ 
service  organizations  called  Information  Technology  Facilities  (ITF).  The  impetus 
for  these  changes  is  the  need  to  reduce  redundant  systems  in  these  functional 
areas.  As  an  example,  it  was  stated  that  there  are  twenty-six  separate  payroll 
systems  throughovt  the  DoD.  In  addition,  it  was  stated  that  DoD  organizations 
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spend  upwards  of  $4  billion  annually  on  development,  maintenance,  and 
modernization  of  information  systems.  The  DoD  comptroller  estimates  that  this 
initiative  should  result  in  total  savings  of  $4.3  billion  from  FY  ’91  to  FY  ’95.  As 
a  result  of  this  initiative,  the  DoD  has  line  item  reduced  DON  ADP  budgets,  to 
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take  into  account  the  anticipated  cost  savings  from  CIM.  This  equates  to  $327 
million  annually  over  the  next  five  years. 

The  CIM  initiative  holds  significant  implications  for  DON  IRM  and  IR 
planning  efforts.  Most  importantly,  the  directed  spending  freeze  has  made  the 
interim  and  target  architectures  on  systems  currently  under  development 
unattainable.  Second,  it  has  superceded,  although  not  officially,  the  DON  IR 
planning  process,  as  a  result  of  the  spending  freeze,  and  the  pending  consolidation 
of  CDA’s  and  DPI’s.  Planning  for  new  systems  will  continue,  although  existing 
systems  must  suffice. 

The  initiative  calls  for  the  formation  of  two  CIM  study  groups  to  study  the 
issue,  and  to  develop  recommendations  for  DoD-standard  systems.  The  first,  the 
Executive-level  group,  will  report  directly  to  the  DoD  Comptroller,  and  will  be 
comprised  of  senior  DoD  and  industry  officials.  The  second  group,  at  the 
Functional-level,  will  report  to  the  Executive  level,  and  will  be  made  up  from 
experts  in  the  six  functional  areas  listed  above.  The  groups  have  been  given  a 
six  month  to  two  year  window  in  which  to  develop  functional  descriptions  (FD) 
for  systems  in  these  areas.  From  there,  they  will  choose  the  existing  system  that 
most  closely  matches  the  FD,  and  then  will  re-engineer  the  system  to  meet  tri¬ 
service  needs.  The  current  plan  is  to  utilize  a  "structured  approach"  such  as  BSP 
as  the  front-end  planning  tool,  and  KnowledgeWare’s  Information  Engineering 
Workbench  (IEW)  as  the  back-end  tool.  The  prospect  of  using  an  Information 
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Engineering-based  CASE  tool  for  the  study  was  proposed,  and  is  under 
consideration.  Its  use  would  definitely  facilitate  the  process,  because  of  its  strong 
data  orientation,  and  its  ability  to  facilitate  rapid  development  of  a  prototype 
system.  Before  a  tri-service  system  can  be  developed,  data  structures  must  be 
standardized  to  meet  the  needs  of  all  three  services.  The  use  of  functional 
descriptions  to  determine  requirements  would  base  systems  development  on  a 
process-oriented  foundation.  Since  all  three  services  have  substantially  different 
processes  and  needs,  this  would  create  a  highly  unstable  basis  for  a  standard 
system.  In  addition,  the  development  of  functional  descriptions,  supplemented  by 
BSP,  would  be  a  slow,  tedious  process  in  comparison  to  utilizing  automated  IE. 
Finally,  the  user  involvement  inherent  in  the  IE  development  process  is  highly 
desirable  when  building  a  standardized  system  such  as  those  proposed,  because  it 
would  facilitate  communication  between  the  services,  and  would  promote  a  sense 
of  commitment  to  the  process. 
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IV.  COMPARING  THE  INFORMATION  ENGINEERING  CASE  TOOLS 


A.  USE  OF  INFORMATION  ENGINEERING  AND  CASE  IN  THE 

DON 

It  is  imperative  that  DON  management  employ  Information  Engineering  to 
facilitate  its  IR  planning  efforts.  "Information  Engineering  provides  the  discipline 
to  ensure  that...(the  DON)...avoids  multiple,  incompatible,  non-integrated  systems 
that  meet  short  term  needs,  but  which  result  in  significant  data  integration 
problems  and  costs  over  the  long  run."  [Ref.  16:p.  78]  It  is  an  effective 
implementation  vehicle  for  IRM,  and  represents  a  formidable  weapon  for  dealing 
with  the  IR  planning  problems  currently  encountered  by  the  DON.  IE  provides, 
as  one  of  its  major  deliverables,  a  highly  stable  data  model.  This  data  model 
provides  management  with  some  important  advantages.  First,  it  facilitates 
management’s  ability  to  adapt  and  update  the  system  to  meet  changing  functional 
requirements,  because  it  is  data-oriented.  Second,  it  provides  DON  management 
with  a  flexible  framework  upon  which  one  development  effort  can  be  based  on 
another.  Finally,  it  provides  a  rigorous  logical  design  which  provides  increased 
control  and  integrity,  and  decreased  redundancy,  in  the  physical  design. 

IE  serves  as  an  effective  tool  on  which  to  base  DON  standardization  efforts, 
because  the  data  model  has  the  ability  to  incorporate  diverse  and  complex 
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functions  under  an  integrated  architecture.  Top  DON  management  has  the 
perception  that  the  development  of  an  overall  Navy-wide  IS  architecture,  and  the 
planning  and  analysis  tasks  that  must  accompany  it,  are  too  complex  for  the 
application  of  IE.  This  is  unfortunate,  because  Information  Engineering  is  ideally 
suited  for  strategic  and  IR  planning  and  systems  development  in  complex 
organizations,  because  it  models  the  organization  independent  of  its  multiple, 
diverse  functions  and  procedures.  As  a  result,  it  is  capable  of  integrating 
disparate  management  issues  and  information  requirements  into  a  single 
consolidated  architecture.  The  use  of  Information  Engineering  in  the  Department 
of  the  Navy  would  significantly  reduce  the  time  required  to  design  and  field 
information  systems,  and  would  ensure  the  most  efficient  use  of  management’s 
time  in  planning  for  and  managing  the  development  process.  By  providing  a  rigid 
structure  on  which  to  base  IR  planning,  analysis,  and  design,  IE  provides  the 
discipline  necessary  to  significantly  accelerate  the  development  process.  It  allows 
this  acceleration,  while  improving  the  consistency  and  completeness  of  the  design 
relative  to  traditional  methods.  Top  DON  management  would  experience  the 
results  of  their  efforts  through  faster  systems  implementation,  reduced 
maintenance  costs,  improved  project  management,  and  an  overall  reduction  in  the 
applications  backlog  currently  plaguing  the  organization. 

Finally,  the  utilization  of  IE  for  IR  planning  and  development  would  protect 
current  investments  and  funding  by  helping  management  clearly  and  accurately 


56 


determine  and  prioritize  its  information  needs.  A  dearly  defined,  well  integrated, 
and  proactive  IS  plan  would  go  far  in  improving  the  credibility  of  the  Navy’s  IRM 
efforts  in  the  eyes  of  Congress.  The  result  could  be  a  significant  improvement 
in  the  funding  climate. 

B.  CASE  TOOLS  SUPPORTING  INFORMATION  ENGINEERING 

The  Department  of  the  Navy  has  utilized  multiple  tools  for  automating 
various  phases  of  the  systems  lifecycle.  Three  tools,  in  particular,  have  enjoyed 
widespread  use:  Information  Engineering  Systems  Corporation’s  (IESC)  USER: 
Expert  Systems;  Texas  Instruments’  Information  Engineering  Facility  (IEF);  and 
KnowledgeWare’s  Information  Engineering  Workbench  (IEW).  These  products 
were  selected  for  review  in  this  thesis  because  they  are  the  most  widely  used  in 
Department  of  the  Navy  applications,  and  because  they  have  associated 
themselves  with  the  Information  Engineering  methodology,  either  as  a  whole,  or 
in  part.  In  addition,  IESC  holds  an  umbrella  contract  with  the  Naval  Data 
Automation  Command  (NAVDAC)  for  IE  methodology  training,  technical  support, 
and  automated  support  tools  usage. 


I 
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1.  IESC’s  USER:  Expert  Systems 


a.  Overview 

Information  Engineering  Systems  Corporation  was  founded  by  Mr. 
Clive  Finkelstein,  co-developer  of  IE,  in  the  early  1980’s.  In  1984,  IESC  released 
USER:  Expert  Systems,  an  expert  system  and  CASE  product,  which  automates  the 
Information  Engineering  methodology.  Its  support  extends  from  strategic  planning 
to  the  generation  of  computer  applications  that  support  those  plans.  Mainframe, 
mini,  and  micro  computer  applications  are  supported  by  the  product.  The 
integrated  software  package  supporting  the  product  provides  a  class  4  expert 
design  dictionary,  Level  2  expert  modeling  support,  and  Level  2  active 
documentation.  Appendix  A  describes  each  of  these  software  support  tools  in 
more  detail. 

USER:  Expert  systems  provides  expert  systems  support  to  strategic 
development  of  information  in  five  phases,  using  IE: 

1.  Analysis  Phase 

2.  Design  Phase 

3.  Build  Phase 

4.  Prototype  Phase 

5.  Implement  Phase 
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IESC  maintains  that  significant  cost  savings  and  dramatic  gains  in  productivity  can 
be  achieved  using  USER:  Expert  Systems  to  automate  these  phases.  Further, 
since  the  resultant  systems  were  designed  extensively  by  users,  their  ability  to 
meet  all  information  requirements  will  be  enhanced,  and  they  will  be  more  closely 
aligned  to  the  strategic  requirements  of  the  organization. 

b.  Methodology 

Information  Engineering,  as  practiced  by  IESC,  is  composed  of 
three  major  stages:  Analysis,  Design,  and  Generation.  (Formerly  called  Discovery, 
Integration,  and  Implementation,  respectively)  Each  phase  is  made  up  of  a 
number  of  stages.  (Figure  10) 


(1)  Analysis  Phase.  In  the  Analysis  phase,  users,  with  the  aid  of 
the  project  team,  use  strategic  and  tactical  statements  derived  early  in  the  phase 
to  identify  and  define  data  and  the  information  derived  from  the  data  required 
at  the  strategic  and  tactical  management  levels  of  the  organization.  It  is  composed 
of  the  following  stages  and  steps:  [Ref.  5:p.  230] 


1.  Project  Scope  Stage: 

-Identifies  the  project  area 

-Identifies  pertinent  personnel,  including  a  project  leader,  and  obtains 
management  authorization  and  sponsorship 
-Establishes  plans,  tasks,  milestones,  and  funding 

-Identifies  strategic  and  tactical  statements  to  be  used  as  input.  These 
statements  are  derived  through  either  formal  strategic  planning  involving 
top  management,  or  through  informal  planning  sessions  with  lower  level 
management.  Top  management  input  is  received  through  review  of  the 
input  of  the  lower  levels. 
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ANALYSIS 


DESIGN 


Figure  10.  IESC’s  Information  Engineering  [Ref.  5:p.  222] 


-Trains  project  personnel  in  strategic  modeling  (for  top  management)  and 
tactical  modeling  (for  operational  management) 

2.  Strategic  Modeling  Stage: 

-Identifies  and  clarifies  the  mission  and  purpose  of  the  organization 
-Sets  strategic  directions  with  appropriate  management 
-Analyzes  the  strategic  statements  and  directions  for  the  future  derived  in 
the  Project  Scope  phase 

-Broadly  identifies  strategic  data  and  operational  segments  that  generate 
tactical  data  on  which  the  strategic  data  is  based 

3.  Strategic  Objectives  Modeling: 

-Reviews  goals  and  objectives,  concerns  and  issues,  and  policies 
implementing  those  goals,  objectives,  and  issues 
-Determines  performance  criteria 

-Identifies  strategic  data  for  measurement  of  performance  criteria 
-Establishes  performance  ranges  and  controls  for  decision  early  warning 

4.  Strategic  Refinement: 

-Progressively  refines  strategic  data  using  a  formal  approach 
-Establishes  standard  terminology  and  expert  rules  at  the  strategic  level 
-Produces  strategic  data  models  representing  a  strategic  blueprint  for 
management  and  a  basis  for  tactical  modeling 

The  strategic  modeling  stages  are  carried  out  by  responsible  senior 
management  in  the  project  area.  Goals  and  objectives,  concerns  and  issues, 
and  relevant  policies  identified  above  are  used  to  classify  strategic  data  for 
input  into  the  strategic  data  model.  This  model  is  used  to  plan  the 
detailed  tactical  modeling  stage. 

5.  Tactical  Modeling  Stage: 

-Identifies  the  tactical  environment  with  middle  and  operational  managers 
-Expands  the  strategic  data  models  through  analysis  of  markets,  services, 
products,  and  channels 

-Identifies  detailed  tactical  data  of  interest  to  middle  and  operational 
management,  and  data  used  to  derive  strategic  data  of  interest  to  top 
management 

6.  Tactical  Objectives  Modeling: 

-Examines  management  objectives  at  various  levels  in  the  project  area 
-Progressively  refines  objectives,  strategies,  and  tactics 
-Further  refines  strategies  for  later  definition  of  expert  rules 
-Identifies  data  neck  to  manage  achievement  of  objectives 
-Identifies  exception  reports  and  decision  triggers  at  the  tactical  level 
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7.  Tactical  Refinement: 

-Progressively  refines  tactical  data  using  a  formal  approach  applied  against 
each  functional  area  separately 

-Establishes  standard  terminology  and  expert  rules  at  the  tactical  level 
-Produces  tactical  data  models  which  are  a  detailed  blueprint  of  the 
organization 

Much  detail  of  the  project  area’s  data  resource  is  identified  and  refined  in 
the  tactical  modeling  stage.  The  functions  of  the  stage  are  analogous  to 
the  strategic  stage,  except  on  a  more  detailed  level.  In  most,  but  not  all 
cases,  the  tactical  data  model  is  used  as  input  for  operational  modeling. 

8.  Current  Systems  Modeling: 

-Used  with  tactical  modeling  for  current  manual  or  automated  systems,  or 
packages,  needed  for  the  future 

-Formally  cross  checks  data  presently  used  in  existing  source  documents, 
reports,  ledgers,  comPuter  files  etc.  against  tactical  data  models 
-Discards  current  data  not  needed  for  the  future 
-Includes  data  for  the  future  that  was  overlooked  in  previous  stages 

9.  Operational  Objectives  Modeling: 

-Examines  operational  objectives  in  the  project  area 

-Identifies  data  neck  to  manage  achievement  of  objectives 

-Identifies  exception  reports  and  decision  triggers  at  the  operational  level 

10.  Operational  Refinement: 

-Progressively  refines  operational  data  for  each  functional  area  defined 
-Establishes  standard  terminology  and  expert  rules  for  the  operational  level 
-Produces  operational  data  models  for  day-to-day  operation  of  the 
organization 


Current  systems  modeling  does  not  require  the  same  level  of 
expertise  about  the  operation  of  the  business  as  the  previous  stages.  It  serves  as 
a  formal  cross  check  of  the  strategic  and  tactical  data  models  to  ensure  that  all 
fundamental  data  is  identified.  It  can  generally  be  carried  out  by  IS  personnel 
or  systems  analysts  using  existing  source  documentation. 
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(2)  Design  Phase.  The  design  phase  is  an  automated  phase  using 
the  Expert  Design  Dictionary.  Although  it  can  be  applied  after  the  analysis 
phase,  it  is  most  effective  if  it  is  applied  concurrently  with  strategic  and  tactical 
modeling  and  refinement.  In  strategic  design,  the  strategic  data  identified  in  the 
Analysis  phase  is  entered  into  the  Expert  Design  Dictionary;  a  tool  that  fully 
automates  the  Information  Engineering  process,  and  checks  for  data  consistency, 
consistency  across  data  models.  It  automatically  combines  common  data  into  an 
integrated  strategic  model.  The  process  is  analogous  for  tactical  and  operational 
design.  Tactical  and  operational  data  are  entered  into  the  Expert  Design 
Dictionary  concurrently  with  derivation  of  the  models.  The  models  are  analyzed, 
and  common  data  is  then  combined  into  integrated  tactical  and  operational 
models. 


c.  Generation  Phase 

The  integrated  strategic,  tactical,  and  operaiional  data  models 
output  from  the  design  phase  are  utilized  as  the  design  blueprint  for  the  final 
phase:  Generation.  The  Generation  phase  defines  detailed  implementation 
strategies  for  each  part  of  the  integrated  data  models.  These  models  may 
represent  the  conceptual  basis  for  both  manual  and  automated  systems.  Expert 
design  software  automatically  restructures  the  integrated  data  models  in  the 
dictionary  into  submodels  specific  to  each  application,  for  implementation. 
Software,  hardware,  and  communications  facilities,  and  the  physical  design  of  the 
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application  are  determined.  Reports,  and  procedures  are  defined  as  well.  The 
resultant  submodels  provide  a  language-independent  interface  to  information 
systems,  and  provide  a  direct  input  to  the  automatic  generation  of  information 
systems. 


d.  Training  and  Workshops 

The  success  of  an  Information  Engineering  project  is  directly 
related  to  the  commitment  and  training  of  users.  IESC  provides  a  comprehensive 
training  and  quality  assurance  program  to  supplement  its  CASE  product.  This 
program  is  composed  of  six  major  workshops,  plus  executive  and  top  management 
overview  presentations.  The  education  program  is  designed  to  enable  the  project 
team  to  be  self-supporting  as  soon  as  possible,  ensuring  maximum  project 
concurrency  and  high  productivity.  Periodic  quality  assurance  consulting  ensures 
a  consistently  acceptable  product.  The  six  workshops  are  described  below: 


1.  Introductory  Workshop: 

-Definition  of  project  boundaries  and  scope 
Jevelopment  of  preliminary  strategic  and  tactical  data  models 
-Completion  of  management  questionnaires  (2  weeks  prior) 

-Review  and  prioritization  of  preliminary  models  by  top  management 
-Identification  of  personnel  for  later  stages 

2.  Strategic  Modeling  Workshop: 

-Strategic  data  model  developed  from  preliminary  models 

-Review  of  strategic  data  model  by  top  management  to  identify  priority 

tactical  areas 
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3.  Strategic  Management  Workshop: 

-Development  and  refinement  of  relevant  policies,  objectives,  and  strategies 
-Identification  of  critical  success  face  and  measures  of  effectiveness 
-Strategic  gap  analysis 

-Management  review  of  refined  strategic  model  and  strategic  plans 

4.  Tactical  Modeling  Workshop: 

-Extension  of  strategic  data  model  into  several  tactical  data  models 
-Management  review  of  tactical  data  model  to  identify  priority  areas 
-Identification  of  personnel  for  involvement  in  later  phases 

5.  Operations  Modeling  Workshop: 

-Extension  of  tactical  models  of  priority  areas  into  operational  models 
-Detailed  definition  of  the  specific  operational  system 
-Management  review 

6.  Implementation  Workshop: 

-Operations  modeling  and  refinement  of  priority  operational  systems 
-Design  and  implementation  of  applications  with  aid  of  PROLOG  Design 
Knowledge  Base. 


Figure  11  illustrates  a  typical  project  plan,  with  scheduling  of 
education,  modeling,  refinement,  and  implementation.  Note  that  the  entire 
process  lasts  approximately  six  months  on  average.  Modeling  and  refinement  of 
models  and  applications  is  an  iterative  process  throughout  the  project  schedule. 


e.  USER:  Expert  Systems  Software  Product  Description 

The  USER:  Expert  Systems  software  package  represents  an  array 
of  expert  systems  that  automate  the  Information  Engineering  methodology.  This 
software  assumes  that  the  user  has  knowledge  of  the  business,  but  no  signifi¬ 
cant  computer  experience.  The  software  was  designed  primarily  for  use  on 
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microcomputers  since  they  are  the  most  accessible  to  the  business  user.  Hardware 
requirements  such  as  memory,  performance,  and  output  specifications,  for  USER: 
Expert  Systems  are  listed  in  Appendix  B.  The  software  package  comprises  the 
following  expert  systems:1 


1.  USER:  DATA  is  an  Expert  Design  Dictionary  that  is  composed  of  a  Class 
4  Expert  Design  Dictionary  and  a  Strategic  Planning  Dictionary.  It 
provides  support  to  both  users  and  analysts,  and  automates  the  Analysis 
and  Design  phases  of  IE.  It  allows  clear  defini:1  >n  of  the  strategic  data 
resource,  and  the  automatic  integration  of  common  data  throughout  the 
organization. 

2.  USER:  PROJECT  is  an  Expert  Project  Management  System  that  supports 
the  Generation  phase  of  IE.  It  supports  the  identification  and  progressive 
implementation  of  subject  data  bases,  and  automatically  derives  an 
implementation  plan  from  the  data  defined  in  the  Expert  Design 
Dictionary.  Finally,  based  on  the  defined  business  strategies,  it  prioritizes 
the  subject  data  bases  for  future  development  efforts. 

3.  USER:  GENERATOR  is  an  Expert  Development  System  that  supports  the 
Generation  phase  of  IE.  It  automatically  generates  a  PROLOG  knowledge 
base  of  the  strategic  and  tactical  data  models,  and  supports  the  design  of 
screen  forms  and  reports.  Further,  it  automatically  generates  the  data  base 
creation  statements  required  for  automatic  installation  of  the  subject  data 
bases  on  micros,  minis,  or  mainframes  using  a  target  data  base  management 
system  (DBMS).  These  data  bases  and  applications  can  be  prototyped  on 
a  microcomputer  using  USER:  SQL,  a  full  implementation  of  DB2  SOL 
packaged  as  a  part  of  USER:  GENERATION. 

4.  USER:  PROCEDURES  is  an  Expert  Logic  Refinement  System  supporting 
the  Generation  phase.  It  automates  procedure  modeling,  and  automatically 
derives  procedures  and  programs  for  processing  the  data  defined  in  the 
models.  A  detailed  representation  of  this  processing  logic  is  generated 
automatically  using  graphical  procedure  maps  and  structured  English 
statements. 


'  Information  for  this  section  was  drawn  from  Ref.  16:pp.  16-19. 
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5.  USER:  IMPLEMENTATION  provides  a  series  of  Expert  Systems 
Migration  products  that  are  designed  to  translate  systems  developed  with 
USER:  GENERATOR  and  USER:  PROCEDURES  for  migration  to 
minicomputer  and  mainframe  hardware,  operating  systems,  DBMS 
products,  and  languages  independent  of  the  USER:  Expert  Systems  software 
environment. 


The  following  expert  systems  facilities  support  the  software 
products  described  above,  in  order  to  provide  full  capability  to  automate  the 
Information  Engineering  process: 


1.  USER:  ADMIN  is  an  Expert  Systems  Administration  Facility  supporting 
all  USER:  Expert  Systems  products.  It  automatically  verifies  the  integrity 
of  the  Expert  Design  Dictionary,  and  provides  automatic  repair  when 
applicable.  It  supports  multiple  Design  Dictionaries  for  multiple  projects, 
and  provides  a  menu-driven  DOS  shell  for  access  to  MS-DOS/PC  DOS 
facilities. 

2.  USER:  PLOTMASTER  is  an  Expert  Data  Mapping  Facility  offering  a 
Level  2  expert  data  modeling  capability  which  is  fully  integrated  with  the 
Expert  Design  Dictionary. 

3.  USER:UEF  is  an  Expert  Design  Dictionary  Expert  Facility  that 
automatically  generates  the  PROLOG  knowledge  base  with  USER: 
GENERATOR,  and  acts  as  an  open  architecture  export  facility. 


These  software  tools  and  facilities  provide  comprehensive  support 
for  strategic  planning,  data  modeling,  and  system  design  activities,  and  represent 
a  highly  effective  front-end  CASE  tool. 
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f.  Assessment  of  USER:  Expert  Systems 

USER:  Expert  Systems  provides  the  most  comprehensive  front-end 
support  of  the  IE  process  of  the  three  CASE  workbenches  discussed.  It  is  fully 
data-oriented;  relationships  and  restrictions  between  data  are  used  to  group  data 
into  potential  information  systems.  Further,  it  is  the  only  product  on  the  market 
today  that  normalizes  data  to  Fifth  Normal  Form  (5NF).  No  other  product 
normalizes  data  past  Third  Normal  Form.  "An  entity  is  in  fifth  normal  form 
if  it  is  dependent  on  other  occurrences  of  the  same  entity  or  entity  type". 
[Ref.  18:p.  9.13]  In  other  words,  5NF  is  indicated  by  the  presence  of  a  recursive 
relationship.  Normalization  to  5NF  is  particularly  important  to  the  design  of 
expert  business  systems  because  it  enables  intelligence  to  be  built  into  the  data 
model.  Further,  it  permits  the  representation  of  logic  intrinsic  to  the  data  model, 
based  on  the  structure  that  exists  between  related  occurrences  of  a  specific  data 
entity.  [Ref.  5:p.  141]  Thus,  it  allows  the  representation  of  highly  detailed, 
intricate  interrelationships  between  data  elements,  such  as  the  ability  to  define 
technical  substitutes  in  an  inventory  management  system,  or  to  optimize  routing 
of  deliveries  in  a  distribution  system. 

Whereas  most  CASE  products  seek  to  improve  the  productivity 
of  programmers  and  the  software  development  process  as  a  whole,  USER:  Expert 
Systems  is  oriented  towards  management  and  users.  IESC  is  essentially  a  training 
and  technical  support  organization  using  its  CASE  tool  for  support.  As  such,  it 
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provides  an  outstanding  training  tool  for  understanding  the  business  and  its 
functions.  The  product  itself  is  highly  user-driven;  modeling  and  normalization 
are  performed  by  the  user  under  the  guidance  of  IESC  representatives.  Further, 
IESC  conducts  a  series  of  workshops  which  supplement  both  training  and  systems 
development  efforts.  This  user-oriented  approach  has  the  advantage  of  promoting 
user  acceptance,  as  well  as  helping  to  identify  strengths  and  weaknesses  in  the 
organization.  Interviews,  questionnaires,  and  observation  often  only  identifies 
problem  areas  in  an  organization.  Using  IESC’s  user-driven  process,  users  are 
able  to  identify  and  assess  not  only  problem  areas,  but  what  the  organization  is 
doing  right.  One  drawback  of  the  product  is  that  the  success  of  any  project  using 
IESC  support  is  directly  related  to  the  amount  of  user  involvement  and 
management  support  received.  In  addition,  a  commitment  by  management  to  take 
advantage  of  the  training  support  provided  by  IESC  is  vital.  IESC’s  first  U.S. 
Navy  project,  providing  Information  Engineering  support  to  NAVSEA’s 
Comptroller  Directorate  [SEA  01),  failed  due  to  inadequate  training  of  users  and 
a  lack  of  top  management  commitment  to  the  project.  [Ref.  16:p.  96] 

USER:  Expert  Systems  is  a  highly  effective  "front-end"  tool, 
providing  comprehensive  support  for  strategic  planning  methodology  and  business 
training,  strategic  data  modeling,  and  tactical  data  modeling.  It  falls  short 
however,  in  support  of  "back-end"  processes  such  as  process  modeling  and  code 
generation.  Further,  it  does  not  support  a  centralized  data  dictionary,  capable  of 
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fully  and  automatically  integrating  data  structures  from  multiple  workstations. 
Both  of  these  items  are  "in  the  works",  with  the  most  likely  solution  being  the 
integration  of  USER:  Expert  Systems  with  an  established  back-end  tool  such  as 
MAGEC,  and  CASE  integrator  such  as  ASYST.  Finally,  the  software  is  not 
always  "user-friendly",  as  much  of  it  is  still  immature. 

2.  Texas  Instruments’  Information  Engineering  Facility  (IEF) 
a.  Overview 

Texas  Instruments  (TI)  began  automating  Information  Engineering 
for  internal  use  in  1983.  As  TI  continued  to  develop  the  process,  it  recognized 
the  practicality,  and  potential  marketability,  of  using  automated  IE  for  applications 
development.  The  Information  Engineering  Facility  (IEF)  was  the  result.  IEF 
consists  of  four  integrated  toolsets  which  together,  automate  the  entire 
Information  Engineering  process,  from  planning,  through  analysis,  design,  and  code 
generation.  IEF  implements  the  major  IE  diagrams,  passes  information 
automatically  between  diagrams,  performs  consistency  checks  and  transformations 
between  stages,  and  finally,  writes  the  source  code.  Three  of  the  four  toolsets, 
Planning,  Analysis,  and  Design,  are  PC-based,  and  work  from  information  residing 
in  local  encyclopedias.  The  fourth  toolset,  a  Code  and  Data  Base  Generator, 
resides  on  a  mainframe,  as  does  the  heart  of  the  system,  the  Central 
Encyclopedia.  The  Central  Encyclopedia,  a  sophisticated  DBMS  and  control 
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system,  acts  as  a  central  repository  for  business  models  under  construction,  and 
as  a  project  management  system.  Figure  12  illustrates  the  IEF  environment. 


b.  Methodology 

The  IEF  is  based  on  James  Martin’s  variant  of  Information 
Engineering.  It  models  the  business  rather  than  isolated  systems,  and  views  the 
development  of  information  systems  in  terms  of  three  components:  business  Data, 
business  Activities,  and  Interaction  between  the  two.  Information  Engineering 
incrementally  refines  each  of  these  three  components,  and  then  integrates  them 
to  form  executing  applications.  This  refinement  takes  place  in  seven  stages,  with 
each  of  the  three  components  becoming  more  detailed  than  in  the  preceding 
stage.  The  seven  stages  and  their  associated  objectives  are:  [Ref.  19:pp.  35-39] 


1.  Information  Strategy  Planning  (ISP): 

-Assess  the  information  requirements  of  the  organization 
-Construct  an  Information  Architecture  to  meet  those  requirements 
-Construct  a  Business  System  Architecture  to  support  implementation  of  the 
Information  Architecture 

-Identify  the  Technical  Architecture  required  to  support  the  Business 
System  Architecture 

-Develop  a  Mission  Statement,  and  identify  pertinent  environmental  factors 
-Present  findings  to  top  management  for  evaluation  and  action 

2.  Business  Area  Analysis  (BAA): 

-Fully  identify  and  define  the  data  needed  by  the  business  area 

-Identify  and  define  the  business  activities  of  each  business  function 

-Define  the  data  required  for  each  business  activity 

-Identify  the  necessary  sequence  of  business  activities 

-Define  how  each  business  activity  affects  the  data 

-Produce  an  implementation  plan  for  the  Business  System  Design  (BSD) 

stage  by  prioritizing  and  integrating  defined  business  systems 

-Develop  data,  activity,  and  interaction  models  for  each  business  area 
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Figure  12.  The  IEF  Environment  [Ref.  19:p.  27J 
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3.  Business  System  Design  (BSD): 

-Define  human-to-computer  interactions  required  to  carry  out  the  previously 
defined  business  activities 

-Refine  and  describe  the  business  system  required  by  the  organization 
-Develop  procedure  and  data  views  of  each  business  system 
-Develop  screen  and  report  layouts 

4.  Technical  Design  (TD): 

-Tailor  the  business  model  to  a  specific  DBMS 
-Determine  environment-specific  implementation  details 

5.  Construction: 

-Build  application  programs  from  the  integrated  model  prepared  previously 
-Build  application  data  bases 

-Build  additional  environment-specific  constructs  required  for  program 
execution 

-Develop  screen  definitions  based  on  layouts  produced  earlier 

6.  Transition: 

-Develop  a  Transition  Plan  to  include  the  following  issues:  training, 
installation,  final  acceptance  testing,  cut-over,  and  post-implementation 
review 

-Install  the  application  system  and  data  structures  in  a  production 
environment,  based  on  Transition  Plan 

7.  Production: 

-Quality  monitoring  and  performance  measurement 


c.  Workshops  and  Training 

Texas  Instruments  provides  training  workshops  that  are 
recommended  prerequisites  to  using  the  toolsets  they  support.  These  workshops 
are  oriented  more  towards  establishing  user  proficiency  with  the  tools,  than 
towards  methodology  training.  An  ISP  workshop  is  provided  to  train  members 
of  an  "Information  Strategy  Planning  Team,"  made  up  of  management  personnel. 
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in  the  operation  of  the  Planning  toolset.  Prior  to  utilizing  the  Analysis  toolset, 
a  BAA  workshop  is  recommended  to  provide  the  education  necessary  to 
effectively  conduct  the  Business  Area  Analysis  phase  and  use  the  toolset.  Finally, 
T1  provides  a  BSD  workshop  and  a  Data  Structure  Diagram  workshop  as 
prerequisites  for  using  the  design  toolset.  It  is  highly  recommended  that  cognizant 
personnel  attend  the  workshops  in  order  to  ensure  that  they  are  fully  versed  in 
the  operation  of  the  toolsets,  processes,  and  diagrams  they  will  be  utilizing. 

d.  IEF  Software  Product  Description 

The  Information  Strategy  Planning  stage  is  supported  by  the 
Planning  toolset,  and  to  a  lesser  extent,  by  the  Analysis  toolset.  During  the  ISP 
stage,  these  toolsets  assist  the  ISP  team  in  developing  a  framework  on  which  to 
base  the  subsequent  analysis  and  design  of  the  potential  application.  They 
provide  support  for  ISP  through  the  use  of  the  following  set  of  diagramming  tools 
and  editors:2 

1.  Indented  List  Editor:  specifies  organizational  hierarchies  and  business 
activity  hierarchies. 

2.  Matrix  Processor:  automatically  performs  matrix  clustering  and  affinity 
analysis  to  help  segment  the  business  into  business  areas  and  business 
systems. 

3.  Entity  Relationship  Diagramming  tool:  represents  the  information  used  in 
the  business,  including  high-level  entity  types.  Produces  a  high-level  Entity 
Relationship  Diagram. 


Software  product  descriptions  in  this  section  drawn  from  Ref.  18rpp  3MI, 
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4.  Process  Hierarchy  Diagramming  tool:  records  business  activities  in  a  tree 
structure.  Produces  a  high-level  Function  Hierarchy  Diagram. 

5.  Process  Dependency  Diagramming  tool:  records  interdependencies  between 
business  activities.  Produces  a  high-level  Function  Dependency  Diagram. 

During  the  Business  Area  Analysis  stage,  analysts  utilize  the 
Analysis  toolset  to  work  with  business  functions  and  entity  types  grouped  into 
business  areas.  The  IEF  will  automatically  check  the  resultant  Business  Area 
model  for  completeness  and  consistency  throughout  this  stage.  The  following  IEF 
tools  support  the  BAA  phase: 

1.  Entity  Relationship  Diagraming  tool:  represents  facts  about  business  data, 
depicts  relationships  between  entity  types,  and  details  attributes  of  entity 
types. 

2.  Entity  Hierarchy  Diagramming  tool:  partitions  entity  types  into  entity 
subtypes. 

3.  Process  Hierarchy  Diagramming  tool:  records  business  activities  in  a 
hierarchical  fashion,  subdivides  functions  into  processes,  and  defines  process 
information  views  of  entity  types. 

4.  Process  Dependency  Diagramming  tool:  records  the  interdependencies 
between  processes,  identifies  events  that  trigger  processes,  and  depicts 
information  flows  from  objects  outside  the  business  area. 

5.  Process  Action  Diagramming  tool:  specifies  the  detailed  logic  of  processes, 
and  performs  process  stereotyping  on  entity  types. 

In  the  Business  System  Design  phase,  the  IEF  automatically 
transforms  BAA-level  processes,  dependencies,  and  information  views  into  BSD- 
level  procedures,  dialog  flows,  and  data  views.  During  this  phase,  the  IEF 


automatically  checks  the  business  system  model  for  consistency  and  completeness, 
and  transforms  BSD-level  entity  types,  attributes,  and  relationships  into  Technical 
Design  (TD)-  level  records,  linkages,  and  fields.  The  following  tools  support  the 
BSD  phase: 

1.  Dialog  Flow  Diagramming  tool:  defines  procedure  boundaries  and  dialog 
flows,  binds  processes  to  procedures,  specifies  linkages,  and  defines  the 
commands  and  states  that  trigger  these  linkages. 

2.  Screen  Design  tool:  designs  screen  layouts  associated  with  procedures. 

3.  Procedure  Action  Diagramming  tool:  specifies  the  detailed  logic  of 
procedures,  and  automatically  transforms  and  synthesizes  BAA  action 
diagrams  into  more  highly  detailed  BSD  action  diagrams. 


The  Technical  Design  phase  requires  little  human  intervention,  as 
the  IEF  automatically  transforms  previously  defined  data  diagrams  into  Data 
Structure  Diagrams.  Both  the  Design  and  Construction  toolsets  support  this 
phase.  During  the  TD  phase,  the  IEF  automatically  checks  the  business  system 
model  for  consistency  and  completeness,  and  prepares  the  TD-level  records,  fields, 
and  linkages  for  transformation  into  data  bases  during  Construction.  The 
following  tools,  residing  on  the  mainframe,  support  the  this  phase: 

1.  Data  Structure  Diagramming  tool:  optimizes  data  base  transformation. 
Pictorial  representation  of  the  physical  data  base  layout. 

2.  Load  Module  Packaging  Panels:  details  packaging  of  procedures  into 
execution  units,  and  specifies  interfaces  to  external  programs  and  data 
bases. 
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Finally,  in  the  Construction  phase,  the  IEF  writes  100  percent  of 
the  source  code  in  the  target  programming  language.  The  IEF  can  generate 
applications  to  run  under  IMS  DC/DB2,  CICS/DB2,  or  TS0/DB2  in  the  IBM 
MVS  environment.  The  following  mainf rame-resident  tools  support  the 
Construction  phase: 

1.  Data  Base  Generation  Panels:  start  the  automatic  generation  of  data 
definition  language  (DDL)  statements. 

2.  System  Generation  Panels:  initiate  COBOL  source  code  generation  and 
compilation,  and  link/edit. 

3.  Interactive  Diagram  Testing  Panels:  test  application  screens,  run  consistency 
checks,  and  ensure  system  logic  runs  correctly. 

The  IEF  Central  Encyclopedia  is  the  heart  of  the  product,  and 
serves  as  an  information  repository  and  project  management  system  for  all 
systems  currently  under  development.  Data  structures,  diagrams,  structured 
specifications,  and  report  and  screen  layouts  all  reside  in  the  encyclopedia.  The 
following  features  of  the  Central  Encyclopedia  support  the  coordination  of  large 
IS  development  projects: 

1.  Model  sharing  and  distribution 

2.  Actual  and  trial  model  merging 

3.  Administrative  and  statistical  reports 

4.  Multiple  level  security  access 

5.  Support  of  multiple  projects  or  workstations  simultaneously. 
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Figure  13  presents  a  summary  of  IEF  automated  support  of  the  Information 
Engineering  process.  Appendix  C  provides  further  product  specifications  and 
hardware  requirements. 

e.  Assessment  of  the  Information  Engineering  Facility 

Texas  Instruments’  Information  Engineering  Facility  (IEF)  provides 
full  support  of  the  entire  IE  process  from  planning  through  code  generation.  It 
uses  sophisticated  diagramming  techniques  to  supplement  planning,  designing,  and 
implementing  application  systems.  These  diagrams  are  fully  integrated  between 
each  other  and  the  business  model  through  the  mainframe-based  Central 
Encyclopedia.  The  Central  Encyclopedia  is  the  heart  of  the  system,  and  is  a 
major  advantage  of  the  IEF.  It  provides  for  project  coordination,  consistency 
checking,  and  model  sharing,  as  well  as  providing  artificial  intelligence-based 
inferencing  rules  that  enforce  synchronization  between  stages. 

Each  IEF  toolset  uses  a  local  encyclopedia,  which  serves  as  a 
subset  of  the  Central  Encyclopedia,  and  is  fully  integrated  with  it.  In  addi¬ 
tion,  the  IEF  provides  full  transformation  between  toolsets  and  stages  to  ensure 
the  consistency  and  completeness  of  the  business  model.  With  the  exception  of 
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Figure  13.  IEF  Automated  Support  [Ref.  19:p.  40] 
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Planning  ,  these  toolsets  can  be  used  as  stand  alone  CASE  tools  as  well,  although 
this  would  undermine  the  IE  process. 

The  IEF  supports  process  modeling  and  data  modeling  in  all 
phases,  a  feature  not  present  in  IESC’s  product.  Process  modeling  supplements 
the  IE  process  by  representing  activities,  procedures,  and  procedure  steps  in 
diagrammatical  form.  This  allows  analyst  to  view  the  business  from  both  views: 
data  and  activities.  Further,  it  allows  partitioning  of  models  based  on  an 
organization’s  procedures  and  the  processes  that  make  up  these  procedures. 

The  IEF  bases  the  Planning  phase  on  user  involvement,  however, 
all  toolsets  rely  heavily  on  systems  analysts  and  programmers  for  guidance  on  use 
of  the  methodology  and  for  operation  of  the  system.  This  is  contrary  to  IESC’s 
product,  which  is  highly  user-driven.  With  the  IEF,  users  tend  to  distance 
themselves  from  the  systems  development  process  after  Information  Strategy 
Planning,  leaving  the  process  to  ADP-types.  User  involvement  is  a  vital 
prerequisite  to  the  success  of  an  IE  project,  and  therefore,  the  organization  must 
stress  continued  involvement  from  non-ADP  personnel  after  the  Planning  phase 
is  complete.  Another  drawback  of  the  IEF  is  that  it  doesn’t  support  the  rigorous 
data  analysis  and  normalization  that  the  IESC  product  does.  It  normalizes  to 
third  normal  form  (3NF),  as  opposed  to  IESC,  which  fully  normalizes  data  to  fifth 
normal  form.  As  a  result,  the  IEF-produced  business  model  will  not  be  as 
rigorous  and  stable  as  the  IESC  data  model.  Further,  IESC’s  data  analysis  and 
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planning  process  is  much  more  comprehensive,  with  a  stronger  foundation  of 
methodology  training.  On  the  other  hand,  IEF  provides  full  back-end  support 
through  code  generation,  and  a  centrally  managed  information  repository  at  the 
mainframe  level;  two  features  not  supported  by  the  IESC  product.  NAVSUP- 
0482,  project  manager  for  SUADPS,  identified  the  tradeoffs  between  the  IEF  and 
USER:  Expert  Systems,  and  developed  an  automated  bridge  between  the  two. 
This  bridge  allows  them  to  take  advantage  of  the  strong  front-end  features  of  the 
IESC  product,  combined  with  the  back-end  features  and  Central  Encyclopedia  of 
the  IEF. 

3.  KnowledgeWare’s  Information  Engineering  Workbench  (IEW) 
a.  Overview 

KnowledgeWare  was  founded  as  Database  Design,  Inc.  in  1979  by 
James  Martin,  as  a  research,  development,  and  consulting  firm.  In  1985,  it 
became  KnowledgeWare,  Inc.,  and  in  1986,  merged  with  Tarkenton  Software,  in 
order  to  add  application  generation  to  its  product  portfolio.  Today, 
KnowledgeWare  is  the  world’s  largest  vendor  of  CASE  tools.  The  company’s 
strategic  product  line,  the  Information  Engineering  Workbench  (IEW),  is  a  CASE 
toolset  consisting  of  three  PC-based  diagramming  tools  for  planning,  analysis,  and 
design,  a  PC-based  COBOL  generator,  and  a  mainframe-based  COBOL  generator. 
All  of  these  products  revolve  around,  and  are  integrated  with,  a  central 
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encyclopedia.  The  IEW  utilizes  an  open  architecture  approach  that  allows  for 
ready  interface  with  other  company’s  software  products.  On  the  other  hand, 
KnowledgeWare  has  entered  into  a  fully  cooperative  marketing  agreement  with 
IBM,  and  as  such,  IEW  has  been  designed  and  updated  to  maintain  full 
compatibility  with  IBM  hardware  and  software  products. 

b.  Methodology 

The  Information  Engineering  Workbench  is  not  aligned  to  a  specific 

methodology.  KnowledgeWare’s  reasoning  for  this  is  that  their  tool  is  built 

around  general  software  principles,  and  as  a  result,  provides  the  developer  with 

more  flexibility  to  tailor  the  tool  to  their  needs.  They  state  that: 

Few  development  shops  can  apply  a  strict  methodology  to  every 
development  or  maintenance  project.  Many  employ  multiple  methodologies 
or  ’home  grown’  hybrids.  And  everyone  is  faced  with  the  ’quick  and  dirty’ 
applications  that  don’t  warrant  a  comprehensive  formal  technique. 

[Ref.  20:p.  2] 

KnowledgeWare  states  that  users  of  the  IEW  are  free  to  employ  Martin’s 
Information  Engineering,  Yourdon,  DeMarco,  Arthur  Young,  Constantine, 
Rockart’s  CSFs,  BSP,  SSP,  JAD,  Prototyping,  and  many  other  methodologies. 
They  maintain  that  their  product  maintains  the  necessary  engineering  discipline 
over  the  systems  development  process,  without  "constraining"  it  to  a  specific 
methodology. 
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c.  IEW  Software  Product  Overview 

The  IEW  workstation  tools  provide  easy-to-use,  mouse-  driven 
applications  for  creating,  revising,  and  maintaining  most  common  systems 
development  diagrams.  All  the  tools  are  fully  integrated  with  the  central 
Encyclopedia,  and  use  the  expert  system  Knowledge  Coordinator.  The  Knowledge 
Coordinator  ensures  the  consistency,  correctness,  and  completeness  of  all  diagrams 
on  a  real  time  basis.  There  are  six  workstations  that  comprise  the  full  IEW 
product:  (Figure  14) 

1.  Planning  workstation 

2.  Analysis  workstation 

3.  Design  workstation 

4.  Mainframe  Knowledge  Coordinator  and  Encyclopedia 

5.  PC-based  Construction  Workstation 

6.  Mainframe-based  GAMMA  workstation. 

Appendix  D  provides  hardware  requirements  for  IEW.  Product  descriptions  are 
listed  below:3 

The  Planning  Workstation  (IEW/PWS)  is  a  tool  for  managing  and 
analyzing  planning  data.  It  helps  the  systems  analyst  define  an  information 
architecture  by  grouping  and  prioritizing  activities  and  data  into  subject  data 


*8oftwmre  product  descriptions  in  this  section  drawn  from  Ref.  19:pp.  6-9. 
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bases.  Further,  it  helps  the  analyst  organize,  model,  and  evaluate  knowledge 
about  the  enterprise-its  processes,  functions,  and  data,  and  its  organizational 
information  needs.  All  diagrams  are  integrated  using  the  Knowledge  Coordinator 
to  ensure  consistency  between  diagrams.  The  following  diagrams  support  the 
Planning  Workstation: 

1.  Association  Matrix  Diagrammer:  performs  cross-analysis  between  any  two 
objects  of  a  strategic  plan,  providing  a  means  to  document  and  modify  the 
information  requirements  of  the  business  and  the  interrelationships  between 
them. 

2.  Property  Matrix  Diagrammer:  assigns  characteristics,  properties,  and 
priorities  to  individual  planning  objects. 

3.  Entity  Diagrammer:  graphic  method  for  describing  the  information  needs 
of  the  enterprise.  It  allows  the  identification  of  principal  entity  types  and 
the  relationships  between  them. 

4.  Decomposition  Diagrammer:  Creates  and  maintains  hierarchy  diagrams  and 
hierarchical  relationships,  and  alerts  the  analysts  to  circular  relationships. 

The  Analysis  Workstation  (IEW/AWS)  provides  diagramming  tools 
for  both  process  and  data  modeling,  a r  ]  the  definition  of  system  specifications. 
It  is  integrated  with  the  Planning  Workstation  through  the  Encyclopedia,  and 
provides  diagramming  techniques  that  support  many  structured  analysis  techniques. 
The  following  tools  support  the  Analysis  Workstation: 

\.  Decomposition  Diagrammer:  refines  high  level  business  activities  into  lower 
levels  of  detail. 

2.  Data  Flow  Diagrammer:  describes  the  processes  of  the  system  and  how 
data  flows  between  these  processes. 


3.  Entity-Relationship  Diagrammer:  defines  data  requirements  for  the 
processes,  subject  area  data  bases,  and  the  system  as  a  whole. 

4.  Action  Diagrammer:  describes  the  procedural  logic  for  the  lowest  level 
processes  in  the  organization. 

The  Design  Workstation  (LEW  /DWS)  supports  the  transformation 
of  logical  representation  of  the  system  to  the  physical  design.  It  supports  both 
process  and  data-oriented  design,  and  helps  the  designer  capture  knowledge  about 
screen  layouts,  edit  rules,  program  structures,  procedural  logic,  and  data  base  and 
file  structures.  All  diagrams,  and  the  movement  between  those  diagrams,  are 
stored  in  the  Encyclopedia,  and  are  managed  by  the  Knowledge  Coordinator.  The 
following  diagrams  support  the  Design  Workstation: 


1.  Structure  Chart  Diagrammer:  describes  the  hierarchy  between  modules, 
along  with  the  data  that  is  passed  between  those  modules. 

2.  Action  Diagrammer  for  Modules:  describe  detailed  program  logic  and  refer 
to  other  design  objects  like  screens,  subordinate  modules,  segments, 
relations,  and  records. 

3.  Presentation  Diagrammer  for  Screens:  speeds  screen  design  using  mouse 
and  graphics  capabilities. 

4.  Data  Structure  Diagrammer:  creates  and  maintains  record,  relation, 
segment,  and  screen  data  structures  graphically. 

5.  Database  Diagrammer:  represents  the  physical  data  base  design  for 
relational,  hierarchical,  and  flat  file  data  base  implementations. 
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The  Mainframe  Knowledge  Coordinator  and  Encyclopedia 
(IEW/MF)  provides  the  analyst  and  designer  with  project  management,  security, 
reporting,  and  shared  access  capabilities.  It  facilitates  the  sharing  of  information 
between  mwtiple  IEW  workstation  users,  and  consolidates  their  work  into  a 
mainframe  resident  central  encyclopedia. 

There  are  two  application  generators  available  as  part  of  the  IEW 
toolset:  the  PC-based  IEW  Construction  Workstation  (IEW/CWS),  and  the 
mainframe-based  IEW/GAMMA.  Both  provide  full  COBOL  source  code 
generation  and  documentation  from  the  previously  defined  design  specifications. 
From  the  design  specifications,  both  tools  generate  100  percent  of  the  application 
including  full  COBOL  source  code,  screen  maps,  data  base  access  routines,  DDL, 
and  full  documentation. 

d.  Assessment  of  the  Information  Engineering  Workbench 

The  Information  Engineering  Workbench’s  open  architecture 
approach  is  a  significant  selling  point  for  the  product.  Every  toolset  has  import 
and  export  capabilities  that  allow  them  to  take  advantage  of  other  tools  in  the 
IEW  package,  or  be  used  in  conjunction  with  other  firm’s  software  products.  The 
tool  provides  capability  to  interface  with  4GL  products,  DBMS’,  desktop 
publishers,  code  generators,  data  dictionaries,  and  spread  sheets. 

The  IEW  workstations  can  be  used  as  one  integrated  toolset  or  as 
separate  tools  to  meet  a  specific  stage  of  the  development  lifecycle.  As  such,  the 
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IEW  offers  the  integration  of  a  single-vendor  solution,  or  the  flexibility  of 
modularity.  On  the  other  hand,  since  the  product  can  be  used  either  way,  it  does 
not  provide  the  rigid  discipline  necessary  for  an  effective,  engineered,  systems 
development  process.  This  is  due  to  the  fact  that  the  IEW  is  not  based  on  a 
specific  methodology.  KnowledgeWare  states  that  this  approach  leads  to  more 
flexibility  for  the  system  developer,  and  makes  it  possible  to  use  the  tool  to 
create  "quick  and  dirty"  applications.  "Quick  and  dirty"  applications  are  exactly 
what  organizations  should  steer  away  from.  An  integrated  toolset  based  on  a 
specific,  rigid  methodology  is  necessary  in  order  to  provide  the  organization  with 
the  rigorous  data  analysis  and  validation  necessary  to  create  strategic  information 
systems.  KnowledgeWare  does  not  provide  training  workshops  or  technical 
support  as  part  of  their  package. 

4.  Comparison  of  CASE  Toolsets 

Both  the  TI  and  IESC  tools  support  Information  Engineering  exclusively, 
as  opposed  to  IEW,  which  professes  to  support  both  data  and  process  orientations 
through  a  combination  of  methodologies.  As  a  result  of  its  "open"  methodology, 
IEW  lacks  the  rigorous  data  analysis,  validation  capabilities,  and  discipline  needed 
for  the  development  of  strategic  information  systems.  The  IESC  product  has  the 
strongest  data  analysis  capabilities,  in  that  it  is  capable  of  normalization  to  5NF. 
It  does  not,  however,  support  any  process-oriented  analysis. 
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Both  IEF  and  IEW  provide  strong  back-end  support  as  well  as  a  central 
encyclopedia  for  integrating  diagrams  and  stages.  The  1ESC  product,  on  the  other 
hand,  does  not  provide  a  fully  developed  back-end,  nor  does  it  provide  a 
centralized  data  repository.  Both  issues  are  currently  being  rectified  by  IESC. 

The  IESC  product  provides  the  most  comprehensive  training  and 
technical  support  program  of  the  three.  It  is  oriented  towards  training  in  both  the 
Information  Engineering  methodology,  and  towards  proficiency  in  using  the 
product.  IEF  training  workshops  are  specifically  designed  to  train  users  on  how 
to  run  the  package.  IEW  provides  no  technical  support  with  its  package.  The 
training  programs  available  reflect  the  policies  of  each  firm.  Whereas  IESC  bases 
the  use  of  its  product  on  full  participation  of  the  user  and  management 
throughout  the  process,  IEF  is  geared  towards  IS  personnel  after  the  initial 
planning  phase.  IEW  represents  a  CASE  tool  specifically  developed  for  use  by 
systems  analysts  and  designers. 

IEW  is  the  least  expensive  of  the  three  products,  however  it  provides 
the  least  benefits  as  well.  The  TI  and  IESC  tools  cost  approximately  the  same 
for  providing  the  same  coverage.  The  addition  of  back-end  support  must  be 
figured  into  the  cost  of  the  IESC  product,  while  the  cost  of  mainframe  support 
must  be  figured  into  the  price  of  the  TI  product.  The  IESC  product  is  fully 
microcomputer-based,  whereas  the  TI  product  requires  both  PC  and  mainframe 
support.  IEW  offers  either  PC  or  mainframe  support. 
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The  next  section  will  compare  the  lifecycle  coverage  of  the  three  CASE 
workbenches  in  the  context  of  an  analytical  framework  for  comparing  IE  methods, 
proposed  by  Hackathom  and  Karimi.  TABLE  1  provides  a  graphical  comparison 
of  the  three  products. 

5.  A  Framework  for  Comparing  Information  Engineering  Methods 
a.  Description 

The  analytical  framework  for  comparing  information  engineering 
(IE)  methods  presented  here  was  developed  by  Dr.  Jahangir  Karimi  and  Dr. 
Richard  Hackathom  of  the  University  of  Colorado  at  Denver.  It  encompasses 
two  dimensions,  depth  and  breadth,  which  form  the  axes  of  a  graph  (called  the 
DB-space)  that  compares  the  IE  methods.  The  framework  suggests  roles  for 
developers  and  planners,  and  two  processes,  align  and  exploit,  that  ensure  that 
organizational  goals  and  the  information  systems  architecture  are  properly  aligned. 
[Ref.  2:p.  205] 

The  breadth  dimension  of  the  framework  is  composed  of  five 
phases,  and  represents  an  extension  of  the  traditional  systems  development 
lifecycle.  It  is  extended  in  that  it  includes  strategic  considerations  not  covered  in 
the  systems  lifecycle.  The  breadth  dimension  describes  both  what  is  being  done, 
an  activity,  and  what  will  result,  the  deliverable.  Each  activity  and  its  associated 
deliverable  is  referred  to  as  a  phase.  (Figure  15)  Note  that  the  first  four  phases 
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TABLE  I 


CASE  TOOL  COMPARISON 


IESC 

IEF 

IEW 

Methodology 

data 

data 

open 

PC/mainframe 

PC 

must  use  both 

either 

Normalization 

5NF 

3NF  plus 

3NF 

Interface 

good 

excellent 

excellent 

Availability 

NAVDAC 

contract 

GSA 

GSA 

PC  Toolset 

$135K 

$89K 

$107K 

Mainframe  Tool 

N/A 

$207K 

$164K 

Technical 

Support 

$275K 

$200K 

not  provided 

Total  Cost 

~$500K 

$495K 

$27  IK  (tools 
only) 

[Ref.  21] 
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Implementation 


are  global  to  the  organization,  and  closely  parallel  the  phases  of  information 
engineering.  The  last  phase  of  the  dimension  is  local  to  a  specific  application, 
and  is  software  engineering  oriented. 

The  five  activities  of  the  breadth  dimension  are:  Organizational 
Analysis,  Strategy  to  Requirements  Transformation,  Logical  Systems  Design, 
Logical  to  Physical  Transformation,  and  Systems  Implementation.  The  first  phase, 
Organizational  Analysis,  is  the  most  vital,  and  in  most  cases,  the  most  overlooked. 
The  purpose  of  the  phase  is  to  conduct  an  analysis  of  the  mission  and  nature  of 
the  organization  and  its  environment,  and  to  translate  this  into  a  formal  statement 
of  organizational  goals  and  strategies.  Phase  two,  Strategy  to  Requirements 
Transformation,  entails  modeling  of  the  information  systems  architecture  (ISA) 
which  represents  the  information  flow  requirements  of  the  entire  organization. 
Data,  applications,  geographic,  and  communications  architectures  are  also  defined 
in  phase  two.  "Planning  for  ISA  should  specifically  include  the  implications  of  the 
business  objectives  and  the  organizational  strategic  plan  on  the  strategic  direc¬ 
tion  setting  of  information  systems  technology.  It  requires  primarily  business- 
oriented  people  who  understand  the  information  requirements  of  the  organization." 
[Ref.  22:p.  11]  The  third  phase  of  the  Breadth  dimension  is  Logical  Systems 
Design.  Its  purpose  is  to  conduct  the  design  of  the  data,  application,  and 
geographic  architectures  using  the  logical  model  of  the  ISA.  Phase  four,  Logical 
to  Physical  Transformation,  consists  of  the  decomposition  of  the  architectures 
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discussed  above,  the  formulation  of  an  applications  portfolio,  and  decision  making 
regarding  detailed  design  and  implementation.  The  final  phase,  Systems 
Implementation,  occurs  for  each  application  designed  in  the  previous  phases.  The 
result  is  an  operational  application  that  supports  a  business  function  of  the 
organization. 

The  Depth  dimension  of  the  framework  allows  review  of 
information  engineering  methods  as  they  relate  to  both  their  conceptual 
foundation  and  practical  results.  It  is  composed  of  three  stages:  methodology, 
technique,  and  tool.  The  first  stage,  methodology,  defines  the  conceptual  basis 
of  an  IE  activity.  The  second  stage,  technique,  specifies  the  steps  in  performing 
a  specific  IE  activity,  including  the  required  inputs  to  and  results  from  each  step. 
The  final  stage,  tool,  represents  a  tangible  aid  for  performing  a  specific  IE  activity 
for  example,  a  CASE  tool.  The  purpose  of  using  a  tool  is  to  produce  a 
deliverable. 

The  two  dimensions  are  used  together  to  produce  the  framework, 
called  the  DB-space,  for  comparing  IE  methods.  (Figure  16)  The  breadth 
dimension  is  used  as  the  horizontal  axis,  with  the  depth  dimension  as  the  vertical 
axis. 

Considering  the  nature  of  the  four  quadrants  in  Figure  15,  one  can 
characterize  organizational  roles  to  support  the  development  process. 
Counterclockwise  from  the  upper  left,  these  roles  are:  [Ref.  22:p.  15] 
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Figure  16.  The  DB-Space  [Ref.  2:p.  209] 
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1.  Conceptual  Planner:  concerned  with  organizational  strategic  planning  and 
direction  setting,  and  the  establishment  of  corporate  IS  strategy. 

2.  Pragmatic  Planner:  concerned  with  modeling  organizational  structure,  plans, 
policies,  procedures,  and  investment  strategies  to  derive  the  IS  architecture 
(ISA). 

3.  Pragmatic  Developer:  concerned  with  implementing  the  ISA. 

4.  Conceptual  Developer:  concerned  with  conceptual  basis  for  employing 
technology  to  meet  organizational  goals  and  needs. 

A  continual  dialogue  or  process  should  occur  between  the 
Conceptual  Planner  and  the  Pragmatic  Developer  to  ensure  that  the  organization’s 
IS  is  fully  aligned  to  organizational  goals  while  being  able  to  exploit  emerging 
technologies.  These  processes  are  referred  to  respectively,  as  Align  and  Exploit. 
The  Align  process  seeks  to  force  IS  management  to  conform  to  the  mission  and 
policies  of  the  organization.  The  Exploit  process  seeks  to  identify  and  exploit 
opportunities  that  are  feasible  given  the  current  state  of  the  organization  and 
technology.  [Ref.  2:p.  216]  Since  these  two  roles  are  on  separate  conceptual 
levels,  the  Align  process  should  involve  the  Pragmatic  Planner,  and  the  Exploit 
process  should  involve  the  Conceptual  Developer.  They  will  act  as  intermediaries 
to  ensure  clear  lines  of  communication  over  the  two  processes.  (Figure  17)  A 
clear  linkage  between  the  Conceptual  Planner  and  the  Pragmatic  Developer  will 
ensure  that  the  IS  architecture  is  fully  aligned  to  the  overall  business  plan  of  the 
organization.  (Figure  18) 
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CONCEPTUAL  PLANNER  CONCEPTUAL  DEVELOPER 


1)  V 

S  s- 


Figure  18.  Aligning  Strategic  and  IS  Planning  [Ref.  22:p.  14] 
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The  parameters  used  for  comparing  IE  methods  are  based  on  two 
major  characteristics:  the  extent  of  coverage  over  the  depth  dimension,  and  the 
extent  of  coverage  over  the  breadth  dimension.  Extent  of  coverage  over  the 
depth  dimension  details  the  following:  the  knowledge  threshold  of  the  input  or 
analysis  employed,  from  conceptual  to  machine  processable  (tool);  the  extent  of 
knowledge  provided  by  the  output,  from  conceptual  to  machine  processable;  and 
the  extent  of  coverage  of  each,  from  no  coverage,  to  partial,  to  extensive.  Extent 
of  coverage  over  the  breadth  dimension  examines  the  extent  to  which  an  IE 
method  covers  the  lifecycle.  It  looks  at  where  inputs  are  generated,  where 
outputs  are  produced,  and  the  coverage  of  each  method  over  the  applicable  part 
of  the  lifecycle.  Based  on  the  results  of  the  elimination  of  theses  parameters,  the 
IE  method  will  be  mapped  onto  the  DB-space.  The  size  and  placement  of  the 
boxes  representing  each  method  indicates  the  relative  coverage  of  the  method 
over  the  breadth  and  depth  dimensions  of  the  framework.  The  framework  does 
not  subjectively  rate  one  method  over  another,  but  simply  gives  the  planner  an 
indication  of  which  methods  provide  the  necessary  coverage  over  the  dimensions 
of  the  framework  for  the  application  in  question.  It  also  provides  an  excellent 
mechanism  for  comparison  and  integration  of  the  methods,  in  order  to  gain  the 
most  complete  coverage  of  the  systems  lifecycle  as  is  practicable. 
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b.  Using  the  Framework  to  Determine  Coverage  of  Toolsets 


Hackathom  and  Karimi’s  framework  represents  an  easy-to* 
understand  graphical  method  of  comparing  the  coverage  of  various  CASE  tools 
using  common  criteria.  As  stated  earlier,  it  does  not  subjectively  rate  one  tool 
over  another,  but  it  does  provide  the  planner  with  an  effective  diagnostic  method 
for  determining  the  combination  of  tools  needed  to  ensure  full  coverage  over  the 
development  lifecycle.  In  this  section,  each  CASE  workbench  discussed  earlier 
will  be  rated  in  accordance  with  the  evaluation  criteria  of  the  framework,  and 
then  mapped  on  to  the  DB-space  to  graphically  illustrate  the  results.  These 
ratings  will  be  performed  subjectively,  based  on  contacts  with  vendors  and  users, 
supporting  literature,  and  some  personal  experience.  Figure  19  illustrates  the 
coverage  ratings  given;  Figure  20  compares  the  CASE  workbenches  in  the  context 
of  the  framework. 

One  can  see  from  Figure  20  that  no  single  CASE  tool  provides  full 
coverage  over  the  breadth  and  depth  dimensions.  Note  however,  that  using  a 
combination  of  tools,  full  coverage  can  be  accomplished.  Ideally,  the  combination 
of  tools  selected  should  provide  full  coverage  over  all  fifteen  sectors  of  the  DB- 
space.  Integration  of  IEF  and  USER:  Expert  Systems  would  accomplish  this,  and 
would  fully  exploit  the  advantages  of  each  product. 
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Figure  19.  Comparison  of  CASE  Tools 
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Extensive 

Partial 


V.  CONCLUSION 


SECNAV  Instruction  5230.9A,  the  Information  Resource  (IR)  Program 
Planning  guide,  and  SECNAV  Instruction  5230.10,  the  Department  of  the  Navy 
Strategic  Plan  for  Managing  Information  and  Related  Resources 
(IRSTRATPLAN),  document  the  Navy’s  commitment  to  a  top-down  approach  to 
strategic  IS  planning.  However,  in  practice,  its  efforts  have  not  been  particularly 
successful.  Huge  cost  overruns,  unnecessary  duplication,  the  inability  to  integrate 
existing  systems,  and  overall  program  mismanagement  have  resulted  in  a  loss  of 
credibility  and  confidence  for  the  DON  in  Congress.  There  are  several  reasons 
for  these  difficulties.  One  of  the  primary  reasons  is  the  lack  of  understanding  by 
top  DON  management  of  Information  Resource  Management  (IRM)  issues,  and 
in  particular,  the  methodologies  and  tools  available  for  aligning  strategic  and 
information  systems  planning.  Uneasiness  regarding  the  need  for  IRM  and  IR 
planning,  the  organizational  structure  required  to  support  IRM,  and  the  relative 
strengths  and  weaknesses  of  the  various  IS  planning  tools  and  methodologies,  all 
add  to  the  reluctance  of  top  management  to  embrace  these  issues.  Second,  the 
reluctance  of  top  management  to  commit  considerable  resources  to  what  is 
perceived  to  be  an  uncertain  process,  further  complicate  the  IRM  and  IR  planning 
process.  This  problem  has  been  further  complicated  by  the  recent  CIM  initiative, 
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which  has  essentially  put  a  hold  on  the  Navy’s  efforts  to  pursue  effective  IR 
planning  and  management.  It  is  important  for  DON  management  to  understand 
that  IS  planning  methodologies  are  not  a  panacea  and  do  not  provide  an 
overnight  payback.  The  large  up  front  investment  in  time  and  capital  required 
will  yield  benefits  downstream,  and  over  the  long  run,  not  overnight.  A 
commitment  to  education  at  all  levels  of  both  the  IS  and  line  communities  is 
required  to  improve  the  overall  performance  of  DON  system  development  and 
program  management. 

The  impact  of  information  technology  varies  widely  between  DON 
organizations,  and  these  differences  influence  greatly  how  IS  planning  can  best  be 
accomplished.  Four  factors  influence  how  the  DON  should  structure  its  IR 
planning  in  order  to  succeed.  First,  the  organizational  placement  of  IS 
management  must  suit  the  role  that  the  information  system  plays  in  the 
competitive  strategy  of  the  business.  In  many  organizations,  including  the 
Department  of  the  Navy,  IS  management  is  relegated  to  the  departmental  level 
despite  the  strategic  significance  of  both  existing  IS,  and  its  applications 
development  portfolio.  As  a  result,  IS  is  perceived  by  top  management,  not  as 
a  corporate  resource,  but  in  a  supporting  role.  Thus,  the  IR  planning  process  was 
relegated  to  the  same  position.  The  location  of  IS  management  in  the 
organizational  structure  must  be  high  enough  for  the  manager  to  have  the  political 
strength  essential  to  positively  plan  and  implement  IS  strategy,  plans,  and  policies. 
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Second,  information  systems  and  general  management  must  be  in  close  proximity, 
both  physically  and  logically,  in  order  to  facilitate  the  IS  planning  process.  Face 
to  face  interaction  is  vital  to  ensure  that  all  information  requirements  are 
identified,  communicated,  and  met.  Third,  as  the  formality  of  the  organization’s 
management  style  and  corporate  culture  increases,  so  must  the  formality  of  the 
IS  planning  process.  In  a  formal  organizational  environment  such  as  in  the 
Department  of  the  Navy,  there  is  no  room  for  informal  planning  processes  that 
are  incapable  of  fulfilling  all  requirements.  Finally,  as  the  size  and  complexity 
of  the  organization  increases,  the  need  for  formal  IS  planning  processes  increases 
accordingly.  This  is  necessary  to  ensure  the  "broad  based  dialogue  that  is 
essential  to  the  development  of  an  integrated  vision  of  IS."  [Ref.  8:p.  156]  If 
these  factors  are  taken  into  account,  and  are  handled  properly,  IS  planning  can 
establish  the  required  structural  linkage  between  the  business  plan  and  the  IS 
plan,  and  between  IS  management  and  senior  line  management. 

Information  Engineering  provides  an  excellent  opportunity  to  solve  many  of 
the  problems  plaguing  IR  planning,  development,  and  management  in  the  DON. 
It  is  the  most  capable  methodology  available  for  integrating  the  diverse 
information  needs  of  Navy  organizations,  and  represents  a  significant  improvement 
over  BSP  or  process-oriented  methodologies.  The  following  are  some  of  the  more 
important  benefits  of  IE  when  used  in  DON  applications: 
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1.  Objectives-driven  approach  ensures  that  the  resulting  information  systems 
are  fully  supportive  of  the  overall  corporate  strategy. 

2.  Data-oriented  approach  identifies  data  fundamental  to  the  organization, 
and  provides  a  stable  foundation  on  which  to  base  systems  development. 
Further,  it  provides  for  standardization  of  data  across  diverse  organizational 
boundaries,  allowing  for  integration. 

3.  Technology-independence  allows  for  upgrades  and  changes  in  procedures, 
hardware,  DBMS’,  etc.  without  affecting  the  stability  of  the  data  model. 

4.  It  provides  for  rapid  feedback  to  users  and  management,  reducing  systems 
development  time,  and  increasing  confidence  in  the  system. 

5.  It  is  capable  of  being  fully  automated  through  the  use  of  CASE 
workbenches,  speeding  up  development  considerably. 

6.  It  drastically  improves  the  quality  of  the  resultant  information  systems, 
thereby  significantly  reducing  maintenance  costs. 

7.  It  facilitates  standardization  and  Data  Administration  by  providing 
consistent  standards  for  defining,  accessing,  processing,  and  changing  data. 

8.  It  improves  user  and  management  satisfaction  because  they  receive  the 
system  that  meets  their  needs  quickly. 

9.  It  significantly  reduces  total  lifecycle  costs. 


Three  CASE  workbenches  that  support  IE  either  in  part  or  exclusively  were 
discussed.  Two,  Texas  Instruments’  IEF  and  IESC’s  USER:  Expert  Systems  were 
shown  to  be  effective  tools  for  automating  the  IE  process.  IESC’s  product  was 
determined  to  be  the  best  "front-end"  tool,  as  a  result  of  its  rigorous  data  analysis 
and  modeling  capabilities,  allowing  data  normalization  to  5NF.  In  addition,  it 
provided  the  most  comprehensive  training  and  technical  support  of  the  three. 
TI’s  tool  was  determined  to  provide  the  most  effective  "back-end"  support,  with 
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the  added  advantage  of  a  centrally  managed  data  repository.  KnowledgeWare’s 
IEW  was  not  recommended  due  to  its  open  methodology  approach,  which  doesn’t 
provide  the  rigorous  structure,  or  the  data  analysis  and  validation  required  for 
building  strategic  information  systems.  In  addition,  it  does  not  provide 
methodology  training  or  technical  support  to  supplement  its  product.  None  of  the 
three  workbenches  provided  full  coverage  over  the  depth  and  breadth  of 
Hackathorn  and  Karimi’s  framework.  As  a  result,  the  combination  of  using  the 
IESC  tool  for  front-end  support,  and  the  TI  tool  for  back-end  support  and  code 
generation,  would  be  the  optimal  combination.  NAVSUP  0482,  project  manager 
for  the  SUADPS  project,  has  developed  an  automated  bridge  between  the  two 
products  to  facilitate  integration. 
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APPENDIX  A 


[Ref.  23] 


Software  Support  Tools: 

A.  Automated  Data  Dictionaries: 

There  are  four  levels  of  automated  data  dictionaries: 

1.  CLASS  1:  Passive  data  dictionaries 

2.  CLASS  2:  Active,  integrated  data  dictionaries 

3.  CLASS  3:  DP-driven  design  dictionaries 

4.  User-driven  expert  systems  design  dictionaries 

Classes  1  and  2  do  not  provide  support  for  automated  analysis  and  design  of 
information  systems;  most  products  on  the  market  are  one  of  these  two.  Classes 
3  and  4  are  both  data  and  design  dictionaries.  All  three  CASE  products  discussed 
provide  Class  4  support. 

B.  Automated  Data  Modeling: 

There  are  two  levels  of  automated  data  modeling  available  in  CASE 

tools: 

1.  LEVEL  1:  Passive  data  modeling 

2.  LEVEL  2:  Expert  data  modeling 
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Level  1  tools  provide  a  passive  capability  for  the  development  and  maintenance 
of  data  models.  They  must  be  manually  entered  and  maintained.  Level  2  tools 
provide  expert  data  modeling  that  is  fully  integrated  with  a  Class  3  or  4  data 
dictionary. 

C.  Automated  Documentation: 

There  are  two  levels  of  documentation  support: 

1.  LEVEL  1:  Manual  documentation 

2.  LEVEL  2:  Active  documentation 

In  Level  1  documentation,  changes  must  be  input  manually,  and  there  is  little 
support  for  consistency  checking.  Level  2  documentation  is  fully  integrated  with 
a  class  3  or  4  data  dictionary.  Updates  and  changes  occur  automatically  as  design 
changes  are  made. 
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[Ref.  17:pp.  3-4] 

USER:  Expert  Systems  Hardware  Requirements: 

A.  Persona]  Computers: 

1.  Any  fully  compatible  XT/AT/386  machine 

2.  XT/AT  compatible  hard  disk  (20  Mb  min.,  40  Mb  recommended) 

B.  Plotters: 

1.  PH7475A  six  pen  plotter 

2.  Any  fully  compatible  HP7475  plotter 

3.  GRAPHTEK  23000  graphics  plotter 

C.  Printers: 

1.  IBM  graphics  printer  or  fully  compatible 

D.  Monitors: 

1.  Coior  preferable  due  to  use  of  colors  in  software. 

E.  Memory  Requirements: 

1.  Software  requires  almost  all  available  RAM,  and  cannot  operate 
concurrently  with  memory  resident  programs. 
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APPENDIX  C 


[Ref.  19] 

IEF  Hardware  Requirements: 

A.  IEF  Mainframe  Operating  Environment: 

1.  IBM  MVS  operating  system: 

a.  DB2 

2.  TSO/E 

3.  ISPF  Version  2.2 

4.  VS  COBOL  II 

B.  IEF  PC  Operating  Environment: 

1.  PC-DOS,  MS-DOS  3.0  or  higher 

2.  Workstation-mainframe  communications  using  IRMA  and  FORTE 
PJ  (3278/79)  boards 

3.  Plotters/printers 

4.  IBM  AT,  PS/2  Models  50,  60,  80,  and  compatibles 

5.  EGA  graphics 

6.  Mouse 
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APPENDIX  D 


[Ref.  20] 

IEW  Hardware  Requirements: 

A.  IEW  PC-based  Tools: 

1.  IBM  PS/2  Model  50  or  higher  w/  DOS  3.3,  or  IBM  PC/AT  w/ 
DOS  3.1: 

a.  20  Mb  hard  disk 

b.  High  density  disk  drive 

3.  5  Mb  RAM 

4.  Mouse 

5.  VGA/EGA/CGA  graphics 

6.  Laser  or  high  resolution  graphics  printer 

2.  IBM  3270/ AT  (monochrome  only  for  high  resolution) 

1.  5273  System  unit,  model  062 

2.  IBM  5272  color  display 

3.  20  Mb  hard  disk 

4.  High  density  disk  drive 

5.  5  Mb  RAM 

6.  Mouse 

7.  Laser  or  high  resolution  graphics  printer. 
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B.  IEW  Mainframe  Tools: 


1.  IEW/GAMMA  Application  Generator: 

1.  IBM  mainframe  or  plug  compatible  under  MVS  supporting 
ANSI  standard  COBOL  and  VSAM 

2.  TSO/ISPF  and  ISPF/PDF  version  2.0  or  later  and  TSO/E 

2.  IEW/MF  Mainframe  Knowledge  Coordinator  and  Encyclopedia: 

1.  IBM  mainframe  or  plug  compatible  under  MVS/SP  with 
TSO/E  release  2,  ISPF/PDF  V  2  R2,  and  MVS  PROLOG, 
5798-DYL 

2.  4  Mb  region  size  minimum,  6  Mb  recommended 

3.  IBM  file  transfer  software  for  host-PC  link 
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